Issue Station
Sign In
Tools hereToolbox

codex - ✅(Solved) Fix -c config override for projects.<path>.trust_level is not ephemeral and can persist the opposite value to ~/.codex/config.toml [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#18475•Fetched 2026-04-19 15:12:38
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
vieiravieira
Participants
vieiravieira
Timeline (top)
labeled ×3

PR fix notes

PR #18626: Respect explicit untrusted project config

Description (problem / solution / changelog)

Addresses #18475

Why

A -c override such as projects.<cwd>.trust_level = "untrusted" is meant to be a runtime config override, but app-server thread startup treated any non-trusted project as eligible for automatic trust persistence when a permissive sandbox/cwd was requested. That meant an explicit untrusted session override could still cause config.toml to be updated with trusted.

What changed

The app-server auto-trust path now runs only when the active project trust level is unknown. Explicit trusted and explicit untrusted values are both respected, regardless of whether they came from persisted config or session flags.

Changed files

  • codex-rs/app-server/src/codex_message_processor.rs (modified, +1/-1)

Code Example

$ cat ~/.codex/config.toml 
# ...

[tui]
show_tooltips = false
theme = "ansi"

[features]
unified_exec = true

---

$ codex -c "projects={\"$PWD\"={trust_level=\"untrusted\"}}"

---

$ cat ~/.codex/config.toml
# ...

[tui]
show_tooltips = false
theme = "ansi"

[features]
unified_exec = true

[projects."/Users/a/b/c"]
trust_level = "trusted"
RAW_BUFFERClick to expand / collapse

What version of Codex CLI is running?

codex-cli 0.121.0

What subscription do you have?

N/A

Which model were you using?

No response

What platform is your computer?

Darwin 24.6.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Apple Terminal 2.14 (455.1)

What issue are you seeing?

Passing -c to override project trust at startup mutates ~/.codex/config.toml, even though --help describes -c as a runtime override of values loaded from that file. In this case, codex even persisted the opposite value from the cli argument.

What steps can reproduce the bug?

$ cat ~/.codex/config.toml 
# ...

[tui]
show_tooltips = false
theme = "ansi"

[features]
unified_exec = true
$ codex -c "projects={\"$PWD\"={trust_level=\"untrusted\"}}"

codex opens, no prompt is shown.

$ cat ~/.codex/config.toml
# ...

[tui]
show_tooltips = false
theme = "ansi"

[features]
unified_exec = true

[projects."/Users/a/b/c"]
trust_level = "trusted"

-c should not add anything to the config.toml (?) and certainly not the opposite of what it received via cli args.

What is the expected behavior?

  • -c should not persist changes into ~/.codex/config.toml.
  • If the override is accepted, the effective value for that session should be untrusted, not trusted.

Additional information

No response

extent analysis

TL;DR

The issue can be worked around by avoiding the use of the -c flag to override project trust at startup, as it incorrectly mutates the ~/.codex/config.toml file.

Guidance

  • Verify that the issue is specific to the codex-cli version 0.121.0 and the described usage of the -c flag.
  • Check if there are any open issues or pull requests related to this behavior in the Codex CLI repository.
  • Consider using alternative configuration methods or flags that do not modify the ~/.codex/config.toml file.
  • Test the behavior with different values and flags to see if the issue is consistent.

Example

No code snippet is provided as the issue is related to the behavior of the codex-cli tool rather than a specific code implementation.

Notes

The issue seems to be a bug in the codex-cli tool, and the workaround is to avoid using the -c flag until the issue is fixed. The behavior may vary depending on the specific version and configuration of the tool.

Recommendation

Apply workaround: Avoid using the -c flag to override project trust at startup until the issue is fixed, as it can cause unexpected changes to the ~/.codex/config.toml file.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#memory leak#API versioning#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING