macOS: locale-dependent PID start-time comparison deletes live app-server daemon tracking record #43608

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   on Sep 7, 2026
2. argszero commented on Sep 7, 2026

   

   argszero

   on Sep 7, 2026

   More actions

   Confirmed the root cause against current main — this is a genuine locale-sensitivity bug in the pid-managed app-server backend, and the mechanism is precise.

   The locus

   read_process_start_time calls ps -p PID -o lstart= with no locale/env normalization (codex-rs/app-server-daemon/src/backend/pid.rs:625-627 on current main):

   async fn read_process_start_time(pid: u32) -> Result<String> {
       let output = Command::new("ps")
           .args(["-p", &pid.to_string(), "-o", "lstart="])
           .output()
           .await
           ...
   }

   That value is formatted exactly once at launch into PidRecord.process_start_time (pid_start.rs:225,229-231) and persisted in the pid file. Later, process_matches_record → read_process_start_time runs the same ps command again and compares the strings for equality (pid.rs:501-509). The whole identity check is a raw string equality between two ps lstart outputs.

   Why the locale matters

   ps lstart= is locale-bound. I verified this directly on this macOS host (same pid across all four invocations):

   LC_ALL=C                → Tue Sep  8 07:58:23 2026
   LC_ALL=en_AU.UTF-8      → Tue  8 Sep 07:58:23 2026   (day/month order swaps)
   LANG=C                  → 二  9月/ 8 07:58:23 2026    (non-English!)
   

   So the same process yields a different string under a different locale. The bug fires when the writer and reader run under different locales:

   • Capture at launch uses the daemon-spawner's environment (pid_start.rs — e.g. a Codex tool shell forcing LC_ALL=C.UTF-8).
   • Compare later (daemon version / restart / a stale-record cleanup) uses the command's environment, which can be the interactive terminal's locale (en_AU.UTF-8).

   The two no longer match → record_is_active returns false → the daemon treats the live record as stale → refresh_after_stale_record deletes the pid file → app-server daemon restart reports "app server is running but is not managed".

   This also explains the related reports: #37893 (same symptom, no locale cause established) and #9354 (tool shells forcing LC_ALL=C.UTF-8, which is exactly the spawn-time vs terminal-time locale divergence).

   Fix shape (small, contained)

   Both read_process_start_time capture and comparison go through the same function, so the cleanest fix is to make the value environment-stable regardless of what the writer/reader inherit:

   1. Pin the environment for the ps call so the month/day names and ordering are invariant — e.g. run it with a fixed LC_ALL=C (and note timezone: ps lstart shows local time; a differing TZ between spawn and check would also break the string equality, so pin TZ too, or set it to UTC). The capture and comparison then always produce the same string.
   2. Backfill compatibility: already-persisted pid files were written under an unpinned locale, so a record created under en_AU.UTF-8 (Tue 8 Sep ...) won't match a C-pinned reader (Tue Sep 8 ...). Consider a parser that normalizes both to an epoch/time_t (or a canonical %Y-%m-%d %H:%M:%S %z) before comparison, which also future-proofs against timezone drift.

   The lstart format is actually {day} {mon} {daynum} {HH:MM:SS} {year} and the parser would need to handle both %e-style (space-padded day) and the localized month tokens — so a small normalization helper (or forcing LC_ALL=C + TZ and comparing strings) is the pragmatic fix.

   Happy to prepare the patch — it's contained to pid.rs + pid_start.rs + a regression test (the pid_tests.rs harness already calls read_process_start_time(std::process::id()), so an env-pinned test is straightforward).
3. etraut-openai

   closed this as completedon Sep 15, 2026