›_ Codex Issues
Codex Issues / #24855

Codex desktop resumed continuing chat with wrong workspace/cwd and AGENTS.md

Open 💬 3 comments Opened May 28, 2026 by Roy027

Summary

A continuing Codex desktop chat for [WORK_PROJECT_REPO] was resumed/routed with the wrong workspace context: [PERSONAL_FOLDER].

The prompt was typed in an existing project chat, but the model context for the next turn loaded cwd and AGENTS.md from an unrelated personal folder. The assistant then attempted Git/repo operations in that unrelated folder before the mismatch was noticed.

Environment

  • App: Codex desktop
  • App version: 26.519.5221.0
  • OS: Windows 10.0.26200.8457
  • Time observed: 2026-05-28 11:02 +08:00

Expected behavior

A continuing chat thread should preserve the original workspace binding and load the cwd / AGENTS.md associated with that thread's project.

If the app cannot safely restore the original workspace, it should warn the user or ask for confirmation before injecting a different workspace into the model context.

Actual behavior

The continuing chat was presented to the model with:

  • cwd = [PERSONAL_FOLDER]
  • AGENTS.md instructions for [PERSONAL_FOLDER]

This did not match the ongoing conversation, which was about [WORK_PROJECT_REPO].

Impact

  • Private local folder names can be exposed in model context and assistant replies.
  • The assistant may run Git or filesystem commands in an unrelated workspace.
  • The user can lose trust that a continuing project chat is still attached to the intended project.

Privacy note

I am intentionally redacting local paths, repository names, and user-identifying folder names from this public report. I can provide sanitized logs or further details privately if needed.

Mitigation attempted

I added a local global instruction telling Codex to verify that cwd matches the project implied by the conversation before running Git/filesystem/project commands. This is only a mitigation; the underlying issue appears to be in desktop thread/workspace routing or context restoration.

View original on GitHub ↗

3 Comments

Roy027 · 3 months ago

Clarification: the [WORK_PROJECT_REPO] and [PERSONAL_FOLDER] labels in the original report are only privacy-preserving placeholders, not the essence of the bug.

The more general failure mode appears to be: a continuing chat that originally belonged to one workspace can be resumed with the cwd and AGENTS.md from a different currently active/running project or selected workspace. In other words, the issue is not specific to work vs personal folders; the concern is that the desktop app may bind a resumed thread to the wrong active project context.

Expected behavior: each continuing chat should remain bound to its original workspace, or the app should explicitly warn/ask before switching that thread to any different active workspace.

Roy027 · 3 months ago

Privacy/wording correction: please treat the earlier placeholder [PERSONAL_FOLDER] only as a redacted stand-in for another workspace. A better generic framing is:

  • [ORIGINAL_WORKSPACE]: the workspace the continuing chat originally belonged to
  • [OTHER_ACTIVE_WORKSPACE]: a different currently active/running/selected workspace whose cwd and AGENTS.md were injected instead

The issue should not depend on, or reveal, whether either workspace is personal, work-related, or any other category.

it-yusha · 1 day ago

Adding a macOS reproduction and a non-destructive workaround that successfully repaired one existing thread.

Environment

  • ChatGPT Desktop: 26.820.60940
  • Bundled Codex CLI: 0.150.0-alpha.8
  • macOS 26.6.2, arm64

Observed state

  • The saved Desktop project correctly pointed to the intended project directory.
  • One continuing thread still had an old, now nonexistent cwd.
  • Its original session_meta contained the old path.
  • Later turn_context records used the correct path for approximately 407 turns.
  • After reconnecting to the thread, Desktop restored the old cwd at a turn boundary and stopped applying the intended workspace's AGENTS.md.
  • Restarting the app and restarting macOS did not repair it.

I avoided editing state_5.sqlite, rollout JSONL, or Desktop global state directly.

Single-thread recovery that worked

  1. Back up the relevant Codex state.
  2. Fully quit ChatGPT/Codex Desktop so it releases the thread's active writer.
  3. From a separate Terminal, resume the same thread once with the correct working directory and a read-only verification prompt:
codex exec \
  -C /path/to/correct-project \
  -s read-only \
  resume <THREAD_ID> \
  "Confirm the current working directory only. Do not modify files, Git, settings, history, or external state."
  1. Reopen Desktop.
  2. Verify all of the following:
  • Desktop thread-list cwd
  • state_5.sqlite threads.cwd
  • the newest rollout turn_context.cwd
  • a subsequent normal Desktop turn after restart

All four locations matched the corrected path. The original thread ID and history were preserved. No new thread, symlink, or direct state-file edit was required.

Important notes

  • Running this while Desktop still owned the thread safely failed with thread ... already has an active writer.
  • This creates one additional model turn and may consume usage.
  • This repaired one existing thread only. It is not a replacement for an atomic project-wide remap or a supported Desktop "Relink workspace" action.
  • Behavior may vary by CLI version, so users should check their installed CLI help and keep a backup.

A first-party Desktop recovery action would still be preferable: detect an invalid or mismatched cwd, let the user select the correct project root, update the loaded thread safely, and verify persistence after restart.