5.3-Codex isn't very good at remembering that a task is running in the background

Open 💬 1 comment Opened Feb 8, 2026 by khoek

What version of Codex CLI is running?

codex-cli 0.98.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.3-codex

What platform is your computer?

Ubuntu 25.10

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

Gnome

What issue are you seeing?

I've had great success setting codex to run a series of benchmarking tasks, assimilating stats and polling their progress (I just had it run flawlessly for 5hrs until everything was complete). However, the harness/prompts + model fine tuning itself aren't very good at teaching it to not break running background tasks if you try to engage in a discussion while a long running task is running.

What steps can reproduce the bug?

The generic reproduction steps are:

  1. Start a very long task from within codex (perhaps tell it to monitor a python script which finds primes and reports STDOUT progress until it finds the 100 millionth or something).
  2. Ask questions of the model while this task is running in the background, especially tell it to write some code (e.g. "build a visualization script showing on Plotly express charts the progress of the search a function of time", ask it for other visualization ideas, etc). Inevitably, quite fast, it will accidentally cause the background task to be terminated while giving a "final answer" to your last question. (This is definitely not a context window problem.)

I'm not sure how the underlying implementation of the harness is built, but it appears likely to me that codex is telling the harness "I'm done" mistakenly at some stage, and the harness is concluding the task is orphaned and kills it.

I think the harness should probably just be way less aggressive, and prompt the model if it thinks it is trying to give a "final answer" while a task is still running, allowing the model to give it the OK (or not) to do so. I don't know if this last thought is actually relatively easily implementable as your harness is designed, but I hope the idea is clear.

As a stopgap, even just a setting to disable the child-killing behaviour would be great.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗