v0.78.0 panics instead of graceful error when .codex/rules contains invalid Starlark

[r-firpo]

What version of Codex is running?

0.78.0

What subscription do you have?

max

Which model were you using?

No response

What platform is your computer?

No response

What issue are you seeing?

Description

Codex 0.78.0 crashes with a Rust panic when a project contains a .codex/rules file with invalid content (e.g., markdown instead of Starlark). Instead of a parse error, it panics in the system-configuration crate.

Repro

mkdir test-project && cd test-project
mkdir .codex
echo "# some markdown content" > .codex/rules
codex

Expected behavior

Error: Invalid Starlark syntax in .codex/rules at line 1

Or other helpful graceful handling

Actual behavior

thread 'main' panicked at system-configuration-0.6.1/src/dynamic_store.rs:154:1:
Attempted to create a NULL object.

And running codex crashes with no error messaging in the terminal

Analysis

• 0.77.0: Works (likely doesn't read project-local .codex/ directories)
• 0.78.0: Panics
• Both versions bundle system-configuration-0.6.1

The new project-aware configuration feature in 0.78 appears to trigger sandbox/network initialization when processing .codex/rules, which hits a known upstream bug in the system-configuration crate when running under macOS Seatbelt.

Environment

• macOS 26.2 (Darwin 25.2.0)
• Apple Silicon (arm64)
• codex-cli 0.78.0 via npm

Workaround

Remove or fix the invalid .codex/rules file, or downgrade to 0.77.0.

What steps can reproduce the bug?

  mkdir test-project && cd test-project
  mkdir .codex
  echo "# some markdown content" > .codex/rules
  codex

What is the expected behavior?

No response

Additional information

No response

[bolinfest]

@r-firpo I'm very confused right now...

Even when I add RUST_BACKTRACE=1 to a dev build of codex, I do not get what you reported:

thread 'main' panicked at system-configuration-0.6.1/src/dynamic_store.rs:154:1:
Attempted to create a NULL object.

Though it just exits 0 without printing anything.

I'm also confused about how this relates to mullvad/system-configuration-rs#71.

If I run codex exec hi with your step, I at least get the expected:

Error: Fatal error: failed to load execpolicy: failed to read execpolicy files from /Users/mbolin/code/bug-in-codex/test-project/.codex/rules: Not a directory (os error 20)

[bolinfest]

Ah, I do see an error message printed to ~/.codex/log/codex-tui.log when I run codex without arguments:

2026-01-07T18:39:15.180887Z ERROR codex_tui::chatwidget::agent: failed to initialize codex: Fatal error: failed to load execpolicy: failed to read execpolicy files from /Users/mbolin/code/bug-in-codex/test-project/.codex/rules: Not a directory (os error 20)

Also, I guess this eprintln!() has no hope of being displayed given the TUI state:

codex/codex-rs/tui/src/chatwidget/agent.rs

Line 36 in 9179c9d

eprintln!("{message}");

[bolinfest]

@r-firpo I don't believe this has anything to do with system-configuration. I suspect the eprintln!() is never seen because of how we are writing to the terminal at that moment. The AppEvent::CodexEvent that would normally display the error has a similar issue because this all happens before the TUI even really starts.

The AppEvent::ExitRequest sent after it does get honored, which would explain why we are exiting with 0.

I'm working on a fix...

[r-firpo]

@bolinfest Hey Michael, thanks for following up! Makes sense re: issues propagating before the TUI starts (and FWIW i'm not a codex expert, looked at the code for the first time yesterday). Let me add some color as to why i suspected a system-configuration issue. I repro'd on my machine and filtered out the suspicious logs

codex-cli 0.78.0
ryanfirpo@MacBook-Pro-3 codex_bug_evidence % cat ../.codex/rules
test_codex_markdown.md
ryanfirpo@MacBook-Pro-3 codex_bug_evidence % cat crash_output.txt

thread 'main' panicked at /Users/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/system-configuration-0.6.1/src/dynamic_store.rs:154:1:
Attempted to create a NULL object.
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Exit code: 101
ryanfirpo@MacBook-Pro-3 codex_bug_evidence %

Given this, i filtered issues that looked similar and made a naive assumption linking the issue i did (mullvad/system-configuration-rs#71.). I suspect you're probably right that system-configuration may not be the direct root cause, and the TUI error handling might work, but then i guess my question is what in the exit/cleanup path triggered hyper-util → system-configuration → panic? What explains the panic message explicitly coming from that crate with exit code 101? Maybe something that initializes lazily?

Cheers,
Ryan

[r-firpo]

Confirming error handling propagates fine and no panic if the TUI is ready

[bolinfest]

I actually have a proper fix for this in flight in #9011.