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

Resolved 💬 6 comments Opened Jan 7, 2026 by r-firpo Closed Jan 13, 2026

💡 Likely answer: A maintainer (bolinfest, collaborator) responded on this thread — see the highlighted reply below.

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

``bash 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 runningcodex` 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_

View original on GitHub ↗

6 Comments

bolinfest collaborator · 7 months ago

@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 https://github.com/mullvad/system-configuration-rs/issues/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 collaborator · 7 months ago

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:

https://github.com/openai/codex/blob/9179c9deac9230f1ace631c58cc21d404e00e16a/codex-rs/tui/src/chatwidget/agent.rs#L36

bolinfest collaborator · 7 months ago

@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 · 7 months ago

@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

```ryanfirpo@MacBook-Pro-3 codex_bug_evidence % codex --version
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 (https://github.com/mullvad/system-configuration-rs/issues/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 · 7 months ago

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

bolinfest collaborator · 7 months ago

I actually have a proper fix for this in flight in https://github.com/openai/codex/pull/9011.