Remaining background process invisible to LLM

[zimtsui]

What version of Codex CLI is running?

codex-cli 0.120.0

What subscription do you have?

pay as you go

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.12.74+deb13+1-amd64 x86_64 unknown

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

Konsole

What issue are you seeing?

What steps can reproduce the bug?

I cannot be reproduced stably

What is the expected behavior?

The llm should see the process

Additional information

No response

[github-actions]

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

• Codex is not able to access its own background processes after compactation #16580
• '/ps' not showing expected background terminals on Windows #16373
• /stop does not clear background terminals shown by /ps #17311

Powered by Codex Action

[zimtsui]

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

• Codex is not able to access its own background processes after compactation #16580
• '/ps' not showing expected background terminals on Windows #16373
• /stop does not clear background terminals shown by /ps #17311

Powered by Codex Action

It's not a duplicate of them. I didn't compact the context during the background process.

[raye-deng]

This is a significant context awareness gap. When the LLM cannot see a background process it previously started, it loses track of state changes that process may have made — file modifications, dependency installations, database migrations, etc. Subsequent actions are then based on stale assumptions about the file system.

We have observed a similar pattern in multi-session AI coding workflows: the first session starts a background build or test runner, the second session starts before the first completes, and neither session has visibility into the other's file modifications. The result is conflicting writes, overwritten changes, or — worse — both sessions silently succeeding while producing an inconsistent final state.

What makes this class of bug particularly expensive is that it does not produce a clear error. The LLM continues operating normally, just with incorrect assumptions. Downstream actions succeed individually but are logically inconsistent. You only discover the problem later when something breaks in production and the investigation reveals that two conflicting states were written in parallel.

Cross-referencing the final file state against the intended changes is one way to catch this. We built a diff-aware check that compares what the AI said it would do against what actually changed on disk — it catches cases where background processes silently modified files that the main session was also editing.

npx @opencodereview/cli scan . --sla L1 includes file-state consistency checks that can flag conflicting modifications from concurrent AI operations.