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

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.

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.

Start by tracing Codex's filesystem watcher into notify 8.2.0 and the reported fsevent.rs:541 panic on macOS. Reproduce or cover a non-UTF-8 event, then verify malformed paths are handled without aborting the Codex session.