Codex Desktop should distinguish long-context turn stalls from local workspace I/O stalls

What version of the Codex App are you using (From "About Codex" dialog)?

Codex Desktop on Windows. I did not capture the exact app build from the original stuck thread before abandoning it.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

Windows desktop, PowerShell host. The local project involved both a OneDrive-backed Windows path and a later non-synced F:\openclaw\repos\... path.

What issue are you seeing?

Codex Desktop currently makes two very different "stuck" states look too similar to the user:

1. A real local workspace I/O stall caused by a OneDrive-backed project containing large Git/worktree/package-manager state.
2. A long-context Desktop thread/session stall where there was no active local shell/package-manager/Git process, local CPU/RAM pressure was low, and the thread itself appeared degraded or stuck near the model context limit.

The practical result is that users and helper agents can misdiagnose the failure. In my case, moving the project out of OneDrive fixed the local pnpm install / Vite performance problem, but it did not make the old long-running Codex thread safe to continue. The old thread still needed to be abandoned in favor of a short-context continuation.

This is not a request to treat OneDrive as the root cause for every stuck Desktop thread. The opposite: Codex should expose enough phase/state diagnostics to distinguish local workspace I/O problems from app-server/session/context/streaming turn problems.

Concrete observations from the same machine:

• The old Desktop thread was close to the effective context window, around 232k / 258k visible tokens.
• That thread had accumulated large prior diagnostic/tool output, including doctor --fix, rg, and gateway checks.
• At the time of diagnosis, there was no active shell, pnpm, gh, or similar local process explaining the stuck state.
• Local machine resources were not exhausted: CPU was low and RAM still had several GB available.
• A separate OneDrive-backed New project workspace did have a real I/O problem: pnpm install had produced a partially built node_modules of about 90,910 files / 2.8 GB; the same project also had .worktrees around 250,160 files / 6.23 GB and .git around 2.44 GB.
• After cloning/moving the active repo to a non-synced path under F:\openclaw\repos\newproject-fast, dependency install completed in about 17s and Vite was ready in about 2s.
• That fixed the project I/O stall, but it did not change the conclusion that the old long-context thread was already a degraded session and should not be used for continued work.

The missing product behavior is a diagnostic layer that can say, in user-visible terms, which class of stall is happening:

• local command still running;
• local command exited but assistant continuation did not resume;
• workspace I/O is likely blocked by a sync provider or huge file count;
• app-server/thread hydration is slow;
• context compaction is running or failed;
• model/Responses stream is waiting for first output;
• renderer is detached from an active turn;
• no live subprocess and no stream progress, but the thread is near context limit and should be rescued/forked.

What steps can reproduce the bug?

This is easiest to observe with a pair of adjacent failures:

1. Use Codex Desktop on Windows with a long-lived project/GitHub workflow thread.
2. Let the thread accumulate large tool and diagnostic outputs over many turns.
3. Continue until the thread is near the effective context window. In my case it was approximately 232k / 258k.
4. Observe that the thread can appear stuck or unsafe to continue even though the machine has available CPU/RAM and no active local shell/package-manager/Git process is running.
5. Separately, use a Start from scratch / New project style workspace under a OneDrive-backed Documents folder.
6. Run a large JS dependency install there. In my case this created about 90,910 node_modules files and interacted badly with OneDrive / Git / package-manager file churn.
7. Move/clone the repo to a non-synced local path such as F:\openclaw\repos\....
8. Observe that local install/dev-server performance improves dramatically, while the old long-context thread still remains the wrong place to continue the work.

What is the expected behavior?

Codex Desktop should distinguish these states and offer the right recovery path for each:

• If a local command is still running, show the command/process and elapsed time.
• If a command completed but the assistant continuation did not resume, show a post-tool continuation stall state.
• If the workspace is under OneDrive or another cloud-sync known folder and contains large .git, .worktrees, or node_modules trees, warn that the workspace is likely I/O-bound and suggest moving to a non-synced development folder.
• If the thread is near the context limit, has no live subprocess, and has had large prior tool/diagnostic outputs, show a degraded-session warning instead of generic Thinking.
• Offer a first-class rescue path: create a bounded handoff summary, fork a short-context continuation, cancel/abandon the stuck active turn, or export a redacted diagnostic bundle.
• Make it clear when moving the workspace fixes local I/O but does not repair a degraded long-running thread/session.

Additional information

This overlaps with several existing issues, but the point here is the diagnostic boundary between them:

• #25779 for unbounded session/turn state, context bloat, and lost active-turn control.
• #24287 for UI stuck in Thinking / active-turn visibility and cancellation problems.
• #24100 for proactive handoff and rescue workflows.
• #25009 for Desktop slowdown after compaction and large injected transcript/tool histories.
• #27588 for pre-write context-compaction loops.
• #22532 for OneDrive-backed Windows project locations.

I also posted targeted datapoints on the most relevant threads:

• #25779 comment: https://github.com/openai/codex/issues/25779#issuecomment-4710245585
• #24100 comment: https://github.com/openai/codex/issues/24100#issuecomment-4710245535
• #22532 comment: https://github.com/openai/codex/issues/22532#issuecomment-4710245524

Suggested implementation direction:

1. Add a small Desktop/app-server stall classifier that combines local subprocess state, recent stream deltas, context usage, compaction state, thread hydration timing, and workspace path risk.
2. Surface that classifier in the UI instead of collapsing everything into Thinking / Working.
3. Add a no-progress guard for file-editing turns: if there is no live subprocess, no file change, no stream delta, and the context is near the limit, offer a rescue/fork/handoff path.
4. Add a workspace preflight warning for OneDrive/cloud-sync roots with large .git, .worktrees, or node_modules.
5. Keep the two fixes separate in code: a workspace-location warning should not be treated as the repair for long-context session degradation.

This would make future reports easier to triage and would prevent users from continuing in a thread that looks merely slow but has actually become unsafe to rely on.