Codex Security local remediation rejects generated patches when raw directory snapshot contains volatile tooling files
What version of the Codex App are you using (From "About Codex" dialog)?
Version 26.616.71553 - Released Jun 23, 2026
What subscription do you have?
Not provided
What platform is your computer?
Darwin 25.5.0 arm64 arm
What issue are you seeing?
Codex Security local remediation can reject a valid generated patch with:
Working-tree contents changed. Regenerate the remediation patch against the current checkout.
The failure appears when the selected target is a non-git parent directory that contains nested git repositories and volatile local tooling state, such as .codegraph/.
In this setup, the remediation worker can generate a patch artifact, validate that the patch applies cleanly to the intended source files, and keep the selected checkout unmodified. However, recording the remediation as generated fails because the selected directory snapshot changes due to unrelated local runtime files.
This makes the finding's patch state end as failed, even though the generated patch itself is usable.
What steps can reproduce the bug?
- Create or use a parent project directory that is not itself a git repository.
- Put one or more git repositories inside it, for example:
parent/backendparent/frontend
- Enable a local indexing/tooling system that writes volatile files under the parent directory, for example
.codegraph/containing runtime files such as sockets, logs, WAL/SHM files, pid files, or index updates. - Open Codex Security against the non-git parent directory.
- Run a local scan.
- Generate a remediation patch for a finding that only changes files inside one nested repository.
- Observe that patch generation can produce a valid patch artifact, but recording
state="generated"fails with:
Working-tree contents changed. Regenerate the remediation patch against the current checkout.
I also saw the related setup failure earlier when the scan target included a volatile socket:
Unsupported local file type: .codegraph/daemon.sock
What is the expected behavior?
Codex Security local remediation should not fail a generated patch because unrelated volatile local-tooling files changed outside the files touched by the patch.
At minimum, one of these should happen:
- Codex Security should honor explicit exclude paths for local directory snapshots during both scan and remediation integrity checks.
- Known volatile local-tooling directories such as
.codegraph/should be excluded from raw directory snapshot hashing, or surfaced as a recommended exclusion before scan/remediation. - The UI should warn when the selected target is a non-git parent directory and recommend selecting the nested git repository instead.
- The error should identify which path changed, so users can distinguish source drift from unrelated local runtime state.
Additional information
A practical workaround is to select the nested git repository directly, for example backend/, instead of the non-git parent directory. That makes the selected target git-aware and avoids hashing unrelated parent-level tooling state.
The current behavior is confusing because the remediation worker preserves the selected checkout, the patch applies cleanly, and only the workbench state update fails. The user-visible result is a terminal failed remediation even though the patch artifact is valid.