Bug: Codex worktree context leaks across all worktrees (shared chats)

Repro details (extra)

I’m following the same machine/setup used to report issue #19647.

Observed command sequence:

# main repo
cd /home/jacob/outlandish/outlandish_web

# list worktrees
git worktree list

# open all worktrees in VS Code
wtopen() {  # existing helper in ~/.zshrc
  # ...
}

I open all worktrees from the helper, then Codex thread list/context in one worktree appears in others.

Shell state used for Codex

command -v codex
# /home/jacob/.local/bin/codex

codex --version
# codex-cli 0.125.0-alpha.3

grep -n "wtnew\|wtopen" ~/.zshrc
# confirm helper functions are available in this environment

Why this matters

Cross-worktree contamination happens during active parallel coding and can cause wrong-file or wrong-task assumptions in long sessions.

If helpful I can paste a short screen capture / HAR style log next, but at this stage behavior is deterministic and currently fully reproducible on this setup.

same

Codex Mac App Shows Sibling Git Worktrees as Separate Projects but Assigns Chats to the Wrong Worktree

Product

Codex Mac app / desktop app (Version 26.623.141536 • Released Jul 7, 2026)

Environment

• Machine: remote machine (Linux)
• OS: macOS client using Codex app connected to remote machine
• Repo location: /path/to/repo/main
• Git setup: main checkout plus sibling Git worktrees

Summary

The Codex app correctly discovers and displays my sibling Git worktrees as separate projects in the sidebar, but chat/session history is not isolated per worktree.

Chats from multiple worktree projects appear to be grouped under one worktree project, while the other worktree projects show "No chats".

This makes it difficult to use Codex with multiple parallel worktrees because sessions are shown under the wrong project.

Repository Layout

/path/to/repo/main
/path/to/repo/main.worktree-a
/path/to/repo/main.worktree-b
/path/to/repo/main.worktree-c

These are sibling directories, not nested worktrees.

Observed Behavior

In the Codex app sidebar, the projects are listed separately:

main.worktree-a
main.worktree-b
main.worktree-c
main

However:

• main appears to maintain its own sessions correctly.
• main.worktree-a shows multiple chats.
• main.worktree-b shows "No chats".
• main.worktree-c shows "No chats".
• Sessions created or expected under the other worktrees appear to be associated incorrectly, seemingly under main.worktree-a.

Expected Behavior

Each worktree project should have independent chat/session history keyed by its worktree root path.

For example:

/path/to/repo/main.worktree-a  -> chats for main.worktree-a only
/path/to/repo/main.worktree-b  -> chats for main.worktree-b only
/path/to/repo/main.worktree-c  -> chats for main.worktree-c only
/path/to/repo/main             -> chats for main only

Git Diagnostics

For one affected worktree:

git -C /path/to/repo/main.worktree-a rev-parse --show-toplevel

Output:

/path/to/repo/main.worktree-a

Command:

git -C /path/to/repo/main.worktree-a rev-parse --git-common-dir

Output:

/path/to/repo/main/.git

This is normal Git worktree behavior: sibling worktrees have distinct working tree roots but share the main repo's Git common directory.

Suspected Cause

The Codex app appears to use different identity logic for project discovery versus session/history association.

Project discovery seems path-aware, since the app displays each sibling worktree separately. But chat/session history appears to be keyed by shared Git metadata, such as:

git rev-parse --git-common-dir

or another canonical repository identity, instead of the worktree root from:

git rev-parse --show-toplevel

Because all sibling worktrees share /path/to/repo/main/.git, their chats may be getting grouped under one worktree project.

Impact

This breaks a common Git workflow where multiple worktrees are used for parallel feature work, investigations, or offloaded Codex tasks.

The app sidebar becomes unreliable because chats are shown under the wrong worktree or missing from the project where they were created.

Requested Fix

Please key Codex app project chat/session history by the worktree root path, for example:

git rev-parse --show-toplevel

rather than by shared Git common directory:

git rev-parse --git-common-dir

or any other shared repository identity.

For the shared-history / accidental-selection part of this worktree issue, I maintain a small unofficial workaround:

https://github.com/cixiangtao/codex-vscode-project-patch

It locally patches the installed openai.chatgpt extension so Webview-originated thread/list requests include the active vscode.workspace.workspaceFolders paths. Because matching is based on exact saved cwd, separate Git worktree roots can be shown as separate task histories when each worktree is opened as its own VS Code workspace.

Apply it without a global install:

npx -y codex-vscode-project-patch

Restore the official file:

npx -y codex-vscode-project-patch restore

This is only a temporary UI/history mitigation, not a fix for the context-leakage bug reported here. It does not change session ownership, rebind an active thread, enforce filesystem/tool boundaries, or prevent manually resuming a thread from another worktree. Its value is limited to reducing cross-worktree history noise and the chance of selecting the wrong thread.

The CLI uses a strict extension-version and bundle-hash allowlist, creates a verified backup, validates the patched JavaScript, and refuses unknown builds. It modifies the existing local installation and does not redistribute the official VSIX. An upstream fix still needs explicit thread/worktree ownership and safe resume behavior.