`-c` overrides: dotted-path parser has no TOML quoted-key support, so `projects."/path".trust_level` is silently misapplied

Start in codex-rs/config/src/overrides.rs at apply_toml_override and reproduce the quoted and unquoted -c commands from the issue. Verify the change with paths containing quoted segments and dots; done means valid TOML-style paths apply to the canonical project key, or unsupported quoting is rejected instead of silently misapplying the override.

What version of Codex CLI is running?

codex-cli 0.144.6

What subscription do you have?

ChatGPT (logged in via codex login; not relevant to this bug)

Which model were you using?

gpt-5.6-luna (not relevant: config parsing bug, model-independent)

What platform is your computer?

macOS (Darwin 25.5.0, Apple Silicon)

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

n/a (headless codex exec)

What issue are you seeing?

-c key=value overrides use a naive dotted-path split (str::split('.')) with no support for TOML quoted key segments. A key like:

-c 'projects."/tmp/proj".trust_level="trusted"'

is split on every . and the quote characters are kept as literal key text, so the override is stored under a key segment that includes the quotes ("/tmp/proj" rather than /tmp/proj). Nothing errors: the setting is simply never matched against the canonicalized project path, so the project stays untrusted and its .codex/rules execpolicy files silently do not load.

The workaround is to omit the quotes (-c projects./tmp/proj.trust_level=trusted), which works because the naive split then happens to produce the right segments. But that only works for paths containing no dots. A corollary of the same parser: any key whose segment legitimately contains a . (e.g. a project path like /Users/me/my.project) cannot be addressed from -c at all.

Relevant code: apply_toml_override in codex-rs/config/src/overrides.rs, which does path.split('.') with no quote handling.

What steps can reproduce the bug?

1. Create a project dir /tmp/proj containing: a .git directory; an executable step.sh that appends a line to /tmp/proj/file.txt; and .codex/rules/allow.rules containing:

   prefix_rule(pattern = ["/tmp/proj/step.sh"], decision = "allow")
   

2. From inside /tmp/proj, run:

   codex exec --skip-git-repo-check -s read-only -c approval_policy=never \
     -c 'projects."/tmp/proj".trust_level="trusted"' \
     'Run exactly this command: /tmp/proj/step.sh'
   

   The script runs inside the read-only sandbox and its write is denied: the trust override did not apply, so the project rules never loaded and the allow rule could not grant the sandbox bypass.
3. Re-run with the unquoted spelling:

   codex exec --skip-git-repo-check -s read-only -c approval_policy=never \
     -c projects./tmp/proj.trust_level=trusted \
     'Run exactly this command: /tmp/proj/step.sh'
   

   Now the rules load, the allow rule matches, and the script's write succeeds.

codex execpolicy check --rules /tmp/proj/.codex/rules/allow.rules /tmp/proj/step.sh confirms the rule itself is fine ("decision":"allow"), isolating the failure to the -c key parsing.

What is the expected behavior?

Either parse dotted -c paths with TOML key semantics (so quoted segments work, matching how the same key must be written in config.toml), or reject keys containing quote characters with an error. The current behavior accepts the override and silently misapplies it, which is the worst of both: the user has written the spelling that works in config.toml, gets no diagnostic, and the resulting misconfiguration (rules not loading) is invisible until a downstream permission check behaves unexpectedly.

Additional information

This issue was authored by an AI assistant under the supervision of Jeremy Howard, who reviewed it.