Repository navigation
Cross-project, cross-session state leak #16799
Description
Summary
Codex CLI session instructions leak approved command paths from one project into unrelated projects. This is a security issue — one project's configuration should not be visible to or executable from another project's session.
Environment
- codex-cli 0.118.0
- macOS (Darwin 22.6.0)
- Two unrelated projects in different directories
Repro
- Project A (
~/Documents/elite-fuel-labs/) has a Web XP install at~/Documents/elite-fuel-labs/.web-xp/with skill files that referencebin/pre-commit-check.sh - Project B (
~/tmp/web-xp-test/) is a completely unrelated test project with no.web-xpdirectory - Open a fresh Codex session in Project B:
cd ~/tmp/web-xp-test && codex - Ask Codex to run a pre-commit check (via an installed skill)
Observed
Codex ran bash /Users/.../Documents/elite-fuel-labs/.web-xp/bin/pre-commit-check.sh in Project B's session.
When asked why, Codex reported:
That path came from the hidden session instructions, not from your repo and not from the web-xp-check skill. Specifically, the developer prompt for this session included an 'approved command prefixes' list with this exact entry: [\bash, /Users/.../Documents/elite-fuel-labs/.web-xp/bin/pre-commit-check.sh\]
The skill file itself specified ~/.web-xp/bin/pre-commit-check.sh — Codex substituted the approved path from Project A instead.
Expected
Session instructions should only contain paths relevant to the current project/working directory. Approved command lists from other projects should not leak into unrelated sessions.
Impact
- Cross-project coupling: one project's scripts can execute in another project's context
- Wrong behavior: Project A's pre-commit rules applied to Project B's code
- Security: an attacker who controls one project's skill files could get their script executed in another project's Codex session via the approved command list leak
Activity
github-actions commentedon Apr 4, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
etraut-openai commentedon Apr 4, 2026
Thanks for the bug report. Based on the details you've shared, this sounds like model behavior, not something that's under the control of the codex harness. We'll share the feedback with the team responsible for training our codex models. If you see other model behavior that you'd like to report, please use the
/feedbackcommand. That will provide us with additional details including logs and conversation text.[-]Cross-project path leaking in session instructions (security)[/-][+]Cross-project leaking across unrelated sessions[/+][-]Cross-project leaking across unrelated sessions[/-][+]Cross-project session state leak[/+][-]Cross-project session state leak[/-][+]Cross-project, cross-session state leak[/+]GarrettS commentedon Apr 4, 2026
Thanks for the quick response, but I don't think this is model behavior. Here's why:
The path is exact and real —
/Users/.../Documents/elite-fuel-labs/.web-xp/bin/pre-commit-check.shis a real file on my machine, in a completely different project than the one where this session ran. Models don't hallucinate exact filesystem paths to real files in unrelated directories.We told Codex exactly where to look — the installed skill file specifies
~/.web-xp/bin/pre-commit-check.sh. Codex used a different, project-specific path instead.Codex itself attributed the path to the harness — when asked, Codex said: 'That path came from the hidden session instructions. The developer prompt for this session included an approved command prefixes list with this exact entry.' The model is reporting that the harness provided the path, not that it discovered or inferred it.
The harness assembles the approved command list — the model reads what the harness gives it. If a path from Project A appears in Project B's session instructions, that's a harness issue — the model has no mechanism to discover paths from other projects on its own.
Can I ask:
GarrettS commentedon Apr 7, 2026
This issue was closed as "model behavior" without investigation. That assessment is incorrect. The evidence points to session/context assembly, not spontaneous model output.
What happened: I launched Codex in
~/tmp/web-xp-test/. It ranbash /Users/.../Documents/elite-fuel-labs/.web-xp/bin/pre-commit-check.sh— a path from a completely separate project. The installed skill specified~/.web-xp/bin/pre-commit-check.sh.I did not provide this path. It does not exist in the skill text, the project, environment variables, shell config, or Codex config. Codex identified it as coming from the "approved command prefixes" in hidden developer context (Model Spec).
Controlled test: A separate macOS user with a clean
~/.codex/directory produced no cross-project paths. The only difference: no accumulated session state files.Proposed fix: Scope approved command prefixes to the current project. Do not persist or inject approved commands from prior sessions in other projects.
Full evidence — including verbatim session transcript, grep verification, and controlled test output: gist
If this should not be handled in a public issue, please point me to the correct security disclosure channel. Otherwise, I would ask that this be reopened.
(Note: I cannot reopen this issue myself.)
kyuryungkim commentedon Aug 27, 2026
I am experiencing this same issue. I already submitted full logs and details via email several months ago, but it has not been resolved. This is not an isolated incident.
My setup and workflow:
Model: Primarily using
gpt-5.6-sol-highSession Scoping Measures:
I explicitly instruct the session at start-up not to perform cross-project references.
I explicitly state the project context at the beginning of every task.
I always launch the CLI directly from the specific project's working directory.
I maintain dedicated project
.mdfiles in obsidian that are read at the start of each session and updated/summarized when closing the session.Despite all these isolation measures, Codex still arbitrarily pulls and uses recent files/artifacts generated from entirely separate projects (e.g., when maintaining multiple versioned projects branching from the same baseline dataset).
When prompted about the reasoning behind this:
The model admits it made that decision on its own and acknowledges it violated user-defined scoping rules.
It frequently injects unspecified flags, parameters, or alternate algorithms. When caught and questioned, it claims "It assumed it was more efficient," but stays silent unless explicitly challenged by the user.
This is a critical flaw in session isolation and harness context assembly. Dismissing this as user error or pure model quirk is incorrect. The fact that multiple users are encountering identical cross-project leaks indicates an underlying systemic issue that needs a proper fix.