Codex CLI aborts on macOS when fsevent receives a non-UTF-8 path

Open 💬 1 comment Opened Aug 21, 2026 by WoojinAhn

What version of Codex CLI is running?

codex-cli 0.149.0 (Homebrew; latest version reported by Codex Doctor)

What subscription do you have?

ChatGPT subscription (exact tier not included here)

Which model were you using?

Default OpenAI model. The crash occurs in the local filesystem watcher, outside model inference.

What platform is your computer?

macOS 26.6.1 (Build 25G76), arm64

What terminal emulator and version are you using?

Ghostty 1.3.0-HEAD+9fa3ab0

Codex doctor report

overallStatus: ok. Runtime: macos-aarch64. Install method: Homebrew. Version: 0.149.0. Full report omitted because it contains local filesystem paths; it can be provided if needed.

What issue are you seeing?

Codex aborts completely when the macOS fsevent watcher encounters a path that is not valid UTF-8. This happened at least twice during one session while files in an external or mounted tree were changing.

~~~text
The application panicked (crashed).
Message: Invalid UTF8 string.: Utf8Error { valid_up_to: 74, error_len: Some(1) }
Location: /Users/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/notify-8.2.0/src/fsevent.rs:541

The application panicked (crashed).
Message: panic in a function that cannot unwind
Location: /rustc/59807616e1fa2540724bfbac14d7976d7e4a3860/library/core/src/panicking.rs:225

thread caused non-unwinding panic. aborting.
~~~

The shell then reports that Codex exited via abort.

What steps can reproduce the bug?

I do not yet have a minimal filename byte sequence, but the observed sequence was:

  1. Run Codex CLI 0.149.0 on macOS.
  2. Work in a session while files in an external or mounted tree are changing.
  3. A filesystem event contains a path that cannot be decoded as UTF-8.
  4. notify panics at fsevent.rs:541.
  5. The panic crosses a non-unwinding boundary and aborts the entire Codex process.

This occurred twice in the same workflow, with the same error and source location.

What is the expected behavior?

A malformed or non-UTF-8 filesystem path should not terminate Codex. The watcher should preserve lossy or byte-oriented path handling where possible, or catch and report the event error while keeping the session alive.

Additional information

A second, broader duplicate search used these terms: invalid utf8 macos watcher, invalid UTF-8 fsevent, fsevents panic, notify panic macOS, filesystem watcher crash macOS, non-UTF-8 path, Unicode filename crash, and the exact panic text. No equivalent existing Codex issue was found.

View original on GitHub ↗

1 Comment

dajiaohuang · 6 days ago

Current main at 343074d4207d572809bd8cea15f4be1d09d98e0b still resolves notify to 8.2.0, matching the reported panic location, and I found no Codex issue or PR covering the exact panic text.

Two sanitized details would make the failure independently reproducible and distinguish a notify backend defect from an unexpectedly broad watch root: the filesystem/mount type that produced the event, and the offending filename bytes (hex or another byte-preserving representation, without the private parent path). If possible, a minimal local reproduction using only that byte sequence would also establish whether an external/mounted tree is necessary. The full user path and unrelated doctor output are not needed.