Codex Desktop: read_thread.thread.cwd can stay / until a later turn
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.4k
- PR merge metrics
- PR metrics pending
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Codex App 26.820.60940 (build 7119), bundled codex-cli 0.150.0-alpha.8
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Darwin 25.6.0 arm64 arm
What issue are you seeing?
For some newly created local-project tasks, Codex Desktop reports thread.cwd="/" even though the task rollout records the requested project cwd in both session_meta.cwd and the first turn_context.cwd. The Desktop value changes to the correct project cwd immediately after a second turn is started with an explicit cwd.
This makes a pre-turn guard that treats thread.cwd as authoritative enter a deadlock: it refuses to start turn 2 until the metadata becomes correct, while the metadata appears to become correct only after turn 2.
What steps can reproduce the bug?
- Create a new local-project task targeting
/Users/den/workspace/songsterr. - Wait for its first turn and rollout to materialize.
- Call the Codex Desktop
read_threadtask-management API. - Compare
read_thread.thread.cwdwith the rollout'ssession_meta.cwdand firstturn_context.cwd. - Start a second turn with the expected cwd explicitly selected.
- Call
read_threadagain.
Observed reproductions:
2026-08-26
- Worker:
01a03dc0-0d67-7ce3-bd38-48d2026c4d8d - Expected cwd:
/Users/den/workspace/songsterr - Desktop
read_thread.thread.cwd:/ - Rollout:
session_meta.cwdand firstturn_context.cwdwere already/Users/den/workspace/songsterr. - Important evidence correction: a later JSON document with the correct cwd was hand-authored by a recovery agent and was not a genuine later Desktop read. No time-based self-heal was observed in this incident.
2026-08-28
- Worker:
01a047d9-7470-7f33-a24e-9a378ca880f1 - Expected cwd:
/Users/den/workspace/songsterr - Desktop reads at approximately
2026-08-28T10:11Zand2026-08-28T10:26Z:thread.cwd="/". - The rollout had the correct cwd in
session_metaand the firstturn_contextfrom task creation. - Immediately after starting turn 2 with the explicit expected cwd, Desktop
read_thread.thread.cwdreported/Users/den/workspace/songsterr.
What is the expected behavior?
read_thread.thread.cwd should report the task session's effective cwd as soon as the first turn and rollout have materialized. If the value is not loaded, the API should expose an explicit unavailable/null state rather than the filesystem root.
Additional information
Local mitigation: for a bound local-project target, / or missing Desktop cwd is treated as non-informative only when session_meta.cwd and the first turn_context.cwd independently equal the expected non-root target. Another non-root Desktop cwd or conflicting rollout evidence remains terminal. The activated turn's actual turn_context.cwd is checked post-dispatch.
This mitigation does not replace an upstream fix because a post-dispatch cwd check can only detect a runtime mismatch after the turn has begun.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Codex Desktop read_thread task-management API and trace how thread.cwd is populated after the first rollout. Reproduce the mismatch by comparing thread.cwd with session_meta.cwd and the first turn_context.cwd, then verify that read_thread reports the effective project cwd immediately after the first turn rather than / or an unavailable value.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- api, devtools
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100