›_ Codex Issues
Codex Issues / #35780

-c config overrides incorrectly split quoted keys containing periods

Open 💬 2 comments Opened Jul 28, 2026 by flyme2bluemoon

What version of Codex CLI is running?

0.145.0

What subscription do you have?

Plus

Which model were you using?

_No response_

What platform is your computer?

_No response_

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

_No response_

Codex doctor report

What issue are you seeing?

The -c/--config override parser does not correctly handle quoted key segments containing periods.

I attempted to mark a newly created temporary directory as trusted for one invocation:

  codex \
      --cd "/private/var/folders/.../T/codex_sandbox.PnNwdssvcN" \
      -c 'projects."/private/var/folders/.../T/codex_sandbox.PnNwdssvcN".trust_level="trusted"'

Codex still displays:

  > You are in /private/var/folders/.../T/codex_sandbox.PnNwdssvcN

    Do you trust the contents of this directory? Working with untrusted contents comes with higher risk of prompt injection. Trusting the directory allows project-local config,
    hooks, and exec policies to load.

  › 1. Yes, continue
    2. No, quit

    Press enter to continue

The quoted project path should be treated as one configuration-key segment. Instead, the override parser splits the key at the period between codex_sandbox and the random suffix.

What steps can reproduce the bug?

  1. On macOS, create and canonicalize a temporary directory:
  sandbox_dir=$(mktemp -d -t "codex_sandbox")
  sandbox_dir=$(cd "$sandbox_dir" && pwd -P)
  1. Launch Codex with an exact project trust override:
  codex \
      --cd "$sandbox_dir" \
      -c "projects.\"$sandbox_dir\".trust_level=\"trusted\""
  1. Observe that Codex asks whether the directory should be trusted.

The problem is reproducible whenever a quoted key segment in a -c override contains a period. It is not specific to temporary directories.

No thread ID is applicable because the prompt appears before a thread starts.

What is the expected behavior?

Codex should provide an unambiguous way to target configuration-map keys containing literal periods.

Ideally, dotted override keys should follow TOML dotted-key syntax, where quoted segments preserve periods. In projects."/tmp/example.with.dots".trust_level, the expected key segments are:

  1. projects
  2. /tmp/example.with.dots
  3. trust_level

If quoted key segments are intentionally unsupported, Codex should reject this syntax with an actionable error and document the inline-table workaround. It should not silently interpret periods inside quotes as nesting separators.

Additional information

The apparent root cause is apply_toml_override in codex-rs/config/src/overrides.rs, which uses path.split('.'). This splits at every period without accounting for TOML quoted-key syntax. The issue potentially affects any map key containing periods, including project paths, domain names, plugin names, and permission-profile names.

A working workaround is to override the entire projects table so the path appears in the TOML value rather than the dotted override key:

  codex \
      --cd "$sandbox_dir" \
      -c "projects={\"$sandbox_dir\"={trust_level=\"trusted\"}}"

A possible fix would be to parse override keys according to TOML dotted-key rules and preserve quoted segments as single keys.

View original on GitHub ↗

2 Comments

tirthfx · 1 month ago

The root cause here is exactly what you found: apply_toml_override in codex-rs/config/src/overrides.rs (line 22) does path.split('.') with no notion of TOML quoted-key syntax, and the key half of a -c key=value override is never TOML-parsed at all — CliConfigOverrides::parse_overrides in codex-rs/utils/cli/src/config_override.rs only TOML-parses the value side (line 72's parse_toml_value); the key is used as a raw string all the way down.

One thing worth flagging beyond the original report: this isn't just "periods inside quotes get treated as separators" — the quote characters themselves aren't stripped either, so a segment like "/tmp/example (with the leading " still attached) becomes a literal table key. That means there's currently no dotted-key spelling that reaches the intended nested key; the inline-table workaround you found is the only way to hit projects."<path>".trust_level today, not just the more ergonomic one.

Two different-sized fixes are plausible here: (1) a real TOML dotted-key tokenizer that respects "..."/'...' quoting and escapes — correct, but it's new parsing logic shared by every -c override in the CLI; or (2) a much smaller change that just detects an unmatched "/' inside a naive .-split segment and rejects the override with a clear error pointing at the inline-table syntax, rather than silently building a wrong config tree. The second doesn't fix the underlying limitation but does close the "silently wrong" failure mode, which seems like the sharper edge of this bug.

hitrich · 1 month ago

I reproduced this on current main and prepared a focused patch locally.

Root cause: apply_toml_override uses path.split('.'), so periods inside quoted TOML key segments are treated as nesting separators and the quote characters are retained.

The proposed fix uses the existing toml_edit::Key::parse dotted-key parser and passes its decoded segments into the existing override logic. If the key is not valid TOML syntax, it falls back to the previous raw-dot-split behavior for compatibility.

I added regression coverage for:

  • the reported quoted project path
  • basic and literal quoted keys
  • escaped Windows-style paths
  • legacy non-TOML key paths
  • quoted profile names interacting with multi-agent configuration

Validation:

  • just test -p codex-config: 231/231 passed
  • just fix -p codex-config: passed
  • just fmt: passed

I have not opened a PR because external contributions are invitation-only. If this approach aligns with the team’s intended behavior, would a maintainer be willing to explicitly invite me to submit the focused patch?