Burning usage credits when specifically asked Codex Luna to stop repeatedly.

Resolved 💬 3 comments Opened Aug 13, 2026 by pcooklin Closed Aug 18, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.147.0

What subscription do you have?

Plus

Which model were you using?

Luna

What platform is your computer?

iMac host ssh to VM Ubuntu 26.04

What terminal emulator and version are you using (if applicable)?

Termius

Codex doctor report

codex doctor --json reports overall status: fail.

  Key findings:

  - Codex: 0.147.0
  - Authentication: configured with ChatGPT tokens
  - App server: stale or unreachable
  - Provider reachability: failed
  - WebSocket reachability: warning
  - Terminal: failed because TERM=dumb
  - State databases: integrity checks passed
  - Rollout state: 15 active files; 2 stale database rows
  - Installation and configuration: consistent
  - No files or settings were changed by the command.

What issue are you seeing?

> I am reporting unexpected and apparently unauthorized Codex usage. A session continued consuming usage after I explicitly instructed it to stop all
> work. Please investigate the session, continuation events, token/usage records, and whether usage can be restored or credited.
>
> Account email: [your email]
> Plan: [plan]
> Approximate time window: [UTC times]
> Session ID: 019fd7eb-8bf8-7ee3-bbef-72c5140695b2
> Reported usage shown: 56,367,765 total tokens
> Evidence attached: screenshots/transcript showing the stop instruction and subsequent activity.

---
you've been burning through my usage all day unknown to me in another session: › stop all work now.

• Stopped. No further work, polling, checks, or background actions will be initiated.

• Context compacted

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
───

• </analysis code> Blank final.

• Context compacted

• Context compacted
Token usage: total=56,367,765 input=53,516,075 (+ 2,590,870,144 cached) output=2,851,690 (reasoning 953,617)
To continue this session, run codex resume, then select MASTER SESSION (019fd7eb-8bf8-7ee3-bbef-72c5140695b2)
[2026-08-13 21:03] [vm] [root]:~ # codex
╭───────────────────────────────────────────────────╮
│ >_ OpenAI Codex (v0.147.0) │
│ │
│ model: gpt-5.6-luna medium /model to change │
│ directory: ~ │
╰───────────────────────────────────────────────────╯

› why did you do that?

• I shouldn’t have allowed that to continue. The explicit “stop all work now” instruction should have terminated the active goal and prevented all
continuations. It appears the session’s continuation/compaction mechanism kept treating the prior task as active, which was a failure to respect the stop
boundary—not something you authorised.

› you've burned half my usage for a week in one day... how do I report this?

• I’ll verify the current official reporting route and the evidence to include.

• Searching the web

• Searched the web for site:help.openai.com contact support report ChatGPT usage billing issue Codex usage

• Ran /srv/scripts/ai-task-route preflight --task "Explain how to report unexpected Codex usage and preserve evidence" --class review
└ Traceback (most recent call last):
File "/srv/scripts/ai-task-route", line 70, in <module>
… +12 lines (ctrl + t to view transcript)
~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: [Errno 30] Read-only file system: '/srv/state/model-routing/20260813T210615Z-85aa38da.json'

• Report it through the OpenAI Help Center chat bubble: How can I contact support? (https://help.openai.com/en/articles/6614161-how-can-i-contact-support)

Use this wording:

Attach the transcript and screenshots of the usage dashboard. Ask specifically for an account-level usage audit and credit restoration.

If you believe the account itself was accessed without authorisation, also email support@openai.com immediately; OpenAI directs users there for
suspicious activity. (OpenAI guidance (https://help.openai.com/en/articles/7242626-how-can-i-report-fraud-or-suspicious-activity))

Do not include passwords, API keys, or other credentials.

• Feedback uploaded. Please open an issue using the following URL:

https://github.com/openai/codex/issues/new?template=3-cli.yml&steps=Uploaded%20thread:%20019ffcf0-cd2f-7be0-a520-000b0e5d1fe9

Or mention your thread ID 019ffcf0-cd2f-7be0-a520-000b0e5d1fe9 in an existing issue.

› codex --version

• Ran codex --version
└ WARNING: proceeding, even though we could not create PATH aliases: Read-only file system (os error 30)
codex-cli 0.147.0

• codex-cli 0.147.0

A warning also reports that PATH aliases could not be created because the filesystem is read-only.

› codex doctor --json

• Ran codex doctor --json
└ WARNING: proceeding, even though we could not create PATH aliases: Read-only file system (os error 30)
{
… +361 lines (ctrl + t to view transcript)
}
}

• codex doctor --json reports overall status: fail.

Key findings:

Codex: 0.147.0
Authentication: configured with ChatGPT tokens
App server: stale or unreachable
Provider reachability: failed
WebSocket reachability: warning
Terminal: failed because TERM=dumb
State databases: integrity checks passed
Rollout state: 15 active files; 2 stale database rows
Installation and configuration: consistent
No files or settings were changed by the command.

› Explain this codebase

gpt-5.6-luna medium · ~ · gpt-5.6-luna · medium · Context 89% left · weekly

What steps can reproduce the bug?

Uploaded thread: 019ffcf0-cd2f-7be0-a520-000b0e5d1fe9

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 14 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#37800
#38266
#37299

Powered by Codex Action

jdcodes1 · 9 days ago

The all-day burn after "stop all work now" is structural in the goal extension, not the model ignoring you.

A goal thread relaunches itself whenever it goes idle: on_thread_idle → continue_if_idle, which starts a new continuation turn as long as the stored goal status is Active (https://github.com/openai/codex/blob/1f41cc5d92/codex-rs/ext/goal/src/runtime.rs#L362-L402). Nothing you did changes that status. A natural-language "stop" message just ends a turn — and a finished turn is the idle trigger, so your stop instruction directly precedes the next auto-continuation. Even a hard interrupt doesn't help: on_turn_abort only records token accounting and returns — it never pauses or defers the goal (ext/goal/src/extension.rs#L275-L300). The only real off-switches are clearing/pausing the goal explicitly, which nothing surfaces at the moment you're trying to stop it.

Fix outline: (1) on a user-initiated interrupt (TurnAbortReason::Interrupted), set the existing continuation-deferral flag (the mechanism is already there, runtime.rs#L371-L380) or flip status to Paused; (2) give the model a pause-goal tool so "stop" in plain language can actually stop it; (3) show an unmissable "goal still active — will auto-continue" notice whenever a goal thread idles.

pcooklin · 9 days ago

The all-day burn after "stop all work now" is structural in the goal extension, not the model ignoring you. A goal thread relaunches itself whenever it goes idle: on_thread_idle → continue_if_idle, which starts a new continuation turn as long as the stored goal status is Active (https://github.com/openai/codex/blob/1f41cc5d92/codex-rs/ext/goal/src/runtime.rs#L362-L402). Nothing you did changes that status. A natural-language "stop" message just ends a turn — and a finished turn _is_ the idle trigger, so your stop instruction directly precedes the next auto-continuation. Even a hard interrupt doesn't help: on_turn_abort only records token accounting and returns — it never pauses or defers the goal (ext/goal/src/extension.rs#L275-L300). The only real off-switches are clearing/pausing the goal explicitly, which nothing surfaces at the moment you're trying to stop it. Fix outline: (1) on a user-initiated interrupt (TurnAbortReason::Interrupted), set the existing continuation-deferral flag (the mechanism is already there, runtime.rs#L371-L380) or flip status to Paused; (2) give the model a pause-goal tool so "stop" in plain language can actually stop it; (3) show an unmissable "goal still active — will auto-continue" notice whenever a goal thread idles.

Many thanks. Yes, got it fixed.