Concurrent Sessions Leak Workspace Root Across Projects

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

• #24186
• #23437
• #23331

Powered by Codex Action

cblanquera-actions (jk)

I checked #24186, #23437, and #23331.

I do not think this is a duplicate of #24186.

• #24186 is a CLI/app-server resume bug where selecting a different cwd during resume is ignored and the resumed session keeps the old cwd.
• My report is about Codex Desktop leaking live workspace/project context between concurrent active chats across different projects.

I also do not think it is a duplicate of #23437, though that one is related.

• #23437 is about codex app-server polluting later TUI session metadata (cwd / source / originator) in persisted records.
• My report is not primarily about persisted metadata attribution. It is about a newly opened Desktop session in Project B behaving as though Project A is still active, including possible leakage of project root, cwd, repo context, file tree/indexing context, and AGENTS.md / SKILLS.md.

#23331 is the closest in impact, but still not the same repro.

• #23331 describes Codex executing commands and editing files in the wrong pinned workspace/repo. (which actually sounds worse than this issue, imo lol)
• My report is specifically about concurrent session isolation: while a long-running chat is active in Project A, a separate chat opened in Project B can inherit Project A’s workspace state.

So I agree these are related, especially around wrong-workspace / wrong-repo integrity failures, but this report is intended to track the distinct concurrent-session Desktop isolation repro.

Thanks @bummerlazarus for potentially identifying the root cause in your https://github.com/bummerlazarus/factory/pull/26 . This is a helpful clue.

Adding a macOS/Codex Desktop data point with persisted JSONL evidence. This appears to be the same workspace/session isolation failure, with one narrower variant: the wrong workspace is already present in session_meta.cwd and the first turn_context.cwd / workspace_roots, before any tool call, skill, or repo-specific command runs.

Environment:

• Codex App: 26.527.60818 (3437)
• Embedded app binary: /Applications/Codex.app/Contents/Resources/codex -> codex-cli 0.136.0-alpha.2
• Platform: Darwin 25.5.0 arm64 arm
• Entry path observed: suggested prompts/new user threads in Codex Desktop while working across several local repos
• The Homebrew terminal CLI is separate from the app binary; updating /opt/homebrew/bin/codex does not explain this because the bad sessions record the app embedded 0.136.0-alpha.2 runtime.

What I found in ~/.codex/sessions/**/rollout-*.jsonl:

| local session id | injected workspace | first real prompt target |
| --- | --- | --- |
| 019e8491-a3ec-7610-9760-64d90b5ac1cf | <DEV>/project-a | <DEV>/project-b / issue-specific task |
| 019e8492-4be8-77c3-aa33-31777d58e560 | <DEV>/project-a | <DEV>/project-c / issue-specific task |
| 019e87e0-bb6c-7aa0-9c7a-11d1f7c1f985 | <DEV>/project-a | <DEV>/project-d / prompt explicitly says Continue in <DEV>/project-d |
| 019e87e1-8d0e-7080-929d-1659a56e113b | <DEV>/project-a | <DEV>/project-e / prompt explicitly says Use <DEV>/project-e |
| 019e87e6-068c-73a2-b836-2e9d56c64e60 | <DEV>/project-a | <DEV>/project-c / prompt references files under that repo |

Common fields on the bad sessions:

• originator = Codex Desktop
• source = vscode
• thread_source = user
• cli_version = 0.136.0-alpha.2
• session_meta.cwd and first turn_context.cwd point to the stale/wrong workspace
• workspace_roots contains the stale/wrong workspace
• the first real user message itself clearly targets another repo, often via an absolute path

Why this matters: this is not only a tool-runtime CWD drift after navigation. In these cases the thread appears to be born with the wrong workspace binding. The model then receives the wrong repo AGENTS.md / workspace context at turn zero, so downstream guardrails in tools or skills can only fail closed; they cannot fully repair the contaminated initial context.

Expected invariant:

selected project/workspace == session_meta.cwd == first turn_context.cwd == workspace_roots == repo implied by the generated/suggested prompt

If Codex cannot satisfy that invariant when launching from a suggested prompt or while multiple sessions are active, it should block the new thread and ask the user to confirm/rebind the workspace before injecting repo-local instructions or enabling file/git/tool operations.

Local mitigation I added: a global instruction requiring the agent to compare the target repo implied by the prompt with the injected cwd/workspace_roots, run pwd and git rev-parse --show-toplevel, and hard-stop on mismatch. That reduces damage, but the bug is upstream in Desktop session bootstrap/workspace binding.

Adding a macOS/Codex Desktop 0.146.0-alpha.9.2 data point with persistent-state and turn-context evidence. This confirms that the leak reaches effective filesystem write permissions, not only sidebar placement or working-directory context.

Observed sequence

• A task for Project A initially had only Project A as its workspace root.
• A separate Project B task was active shortly before the next Project A turn.
• On that next turn, Project B had been appended to Project A’s workspace_roots.
• Project B also appeared as an explicit writable entry in the managed filesystem permission profile.
• Project A’s saved local-project assignment and working directory remained correct.
• The saved projects had no deliberately configured multiple-folder projects.
• Git configuration, project configuration, and trust settings were unchanged.

The incorrect root was persisted in Codex Desktop’s per-thread thread-writable-roots state. Later turns therefore continued receiving real write access to the unrelated project.

A second propagation path was also observed: two new tasks created from another task, while explicitly targeting the correct saved project, inherited the creator task’s visualization directory instead of receiving only their own task-specific visualization root.

Scope

A read-only audit examined 181 stored local-task records. 106 failed the workspace-isolation check, although that count includes historical and archived records. A current task and seven manually created replacement tasks remain clean.

Restarting or replacing a task can produce a clean successor, but it does not repair the contaminated writable-root list stored for an existing task.

Expected behavior

For a single-folder local project, Codex Desktop should rebuild each task’s effective writable roots from:

1. the assigned project folder;
2. that task’s own visualization directory; and
3. ordinary temporary directories.

It should never merge in the previously active project’s root or the creating task’s visualization directory unless the user explicitly attached that folder through Edit project.

If the saved-project assignment and effective writable roots disagree, the task should fail before model or tool execution receives access.

Environment and diagnostics

• macOS 26.5.2, x86_64
• Codex Desktop embedded codex-cli 0.146.0-alpha.9.2
• Restricted managed filesystem sandbox
• codex doctor --json reports the installation, configuration load, state-database integrity, and rollout/database thread inventory as healthy
• Unrelated network and noninteractive-terminal warnings were omitted
• No unrelated root was accessed, and no project files were modified during diagnosis

I retained the exact affected task IDs and timestamped, redacted root transitions and can provide them through a private feedback channel if maintainers request them.

Adding another macOS Codex Desktop data point. Multiple concurrent local tasks abruptly lost their assigned project or worktree root from the effective sandbox writable_roots.

The task CWD remained correct, but affected turns often listed only a task visualization directory as writable. In some records, the visualization directory belonged to another task. Ordinary apply_patch operations inside the correct project CWD were consequently treated as outside-workspace writes and routed through Guardian auto-review, producing repeated declines or internal reviewer errors.

Example shape:

cwd=/Users/<user>/.codex/worktrees/<id>/Development
sandbox_policy=WorkspaceWrite
writable_roots=[
  /Users/<user>/.codex/visualizations/<date>/<thread>
]

The assigned Development worktree was absent. This occurred across multiple active tasks, while other tasks retained the correct project root, suggesting intermittent per-task workspace-state corruption rather than repository permissions.

Restarting Codex restored normal workspace writes. This variant is especially confusing because the CWD and project association remain visibly correct while only the effective write policy is corrupted.

The cross-project leakage makes this a useful persisted session-isolation case. I’m field-testing codex-rescue==0.1.0a4 against durable cwd/workspace/tool-state mismatches.

If you still have a rollout from a session that inherited the wrong project context, could you run a read-only diagnostic:

pipx install codex-rescue==0.1.0a4
codex-rescue doctor --json "/path/to/the-affected-rollout.jsonl"

It won’t fix the Desktop runtime’s project scoping, but it can help distinguish incorrectly persisted session metadata from a purely in-memory/runtime leak.

A sanitized findings/status summary is enough. Please don’t post raw rollouts, databases, prompts, tool arguments/output, credentials, repository names, session IDs, or private paths.