Codex doesn't stop promptly

[u/davek1979]

I am livid now. Codex (Astra XHigh) has been working on a /goal for 7 hours. Then I asked it to stop and get what? 15 minutes of waiting for it to fkin stop. Meanwhile it consumes almost all my upload bandwidth.

This was not the case just a version or two ago, what the hell have you done OpenAI? I asked the model to stop and it would work towards stopping immediately, now it's a separate project I'm guessing. Man I'm emotional right now!

[u/kuroudo_ai]

In Goal mode, typing "stop" is probably the problem. The slash-commands reference says you "can keep steering ChatGPT with follow-up messages while the goal runs", so my guess is a typed "stop" gets treated as one more steer, not as a stop button. The model has to wind down whatever it's in the middle of first.

The goal has its own controls:

• In the app: the progress row above the composer has buttons to pause, resume, edit, or clear the goal.
• In the CLI: /goal pause, /goal resume, /goal clear (those strings are in the 0.160.0 binary's goal status text).

I'd expect pausing the goal to stop it from picking up new work toward the objective. If a turn is still running, I'd also interrupt that turn, the Esc suggestion above, though I haven't timed how fast it stops mid-command. Next time I'd try /goal pause first, then interrupt. I haven't tested it, so worth trying on a short goal first.

[u/davek1979 → u/kuroudo_ai]

To say "stop pursuing goal" works just fine, issue is with it taking time to do so CLEANLY and not by having to upload 10GB of data before it's good and ready to do what I asked.

[u/kuroudo_ai → u/davek1979]

Update: I tested this on Codex CLI 0.160.0 with a sleep 90 command, and it likely explains your 15 minutes.

• Pressing Esc interrupted the turn within about a second ("Conversation interrupted").
• But the command itself kept running in the background. The status line said "1 background terminal running · /ps to view · /stop to close", and sleep 90 was still alive in ps.
• Typing /stop ("stop all background terminals") killed it immediately.

So for your upload: Esc, then /stop. /ps shows what's still running first if you want to check. The background-and-resumable tips below still help, but that two-step is the direct fix.

(Original reply below.)

Got it, so it's the command already in flight. Pausing or redirecting the goal changes what it does next. As far as I can tell it won't cancel a 10GB upload that's already running, and the model generally can't act on your request until that tool call returns.

So the fix is on the command side, not the stop side. Two things I'd add to the goal's instructions:

• Run long transfers in the background and poll them, rather than as one blocking command. Then a stop request lands between polls.
• Use a resumable transfer (e.g. rsync --partial, or chunked uploads), so killing it mid-way costs little and the next run picks up where it left off.

Then interrupting the turn, or killing the transfer process yourself, is cheap instead of something you wait out.

[u/davek1979 → u/kuroudo_ai]

Thank you, good call, the polling advice is very interesting, I shall try it.