All threads freeze at "waiting" until the app is restarted
Version: bb-app 0.36.0 (macOS)
What I was trying to do
Ordinary multi-thread work — several Codex threads running in parallel.
What happened
Every thread on the host stopped advancing and sat at "waiting". Nothing recovered it except quitting and reopening the app. It has now happened four times — once on 08-07 and three times on 08-10.
The server log shows one event being refused over and over:
{"level":40,"time":1786360836499,"eventType":"provider/unhandled","scopeKind":"turn",
"threadId":"thr_fpx3vkax5h","turnId":"auto-compact-1",
"errorMessage":"Cannot append provider/unhandled for turn auto-compact-1 before turn/started is stored",
"errorName":"MissingStoredTurnStartedError","msg":"Rejected daemon event before turn/started"}505 identical rejections between 13:20:36 and 13:25:57, ending only because I killed the app. In that entire window the server logged no thread activity whatsoever — just the rejections.
Every occurrence so far, each ended by a restart rather than by recovery:
| Thread |
Turn |
Rejections |
Window |
thr_dwmzmanhn5 |
auto-compact-2 |
1911 |
08-07 14:57:19 → 15:27:06 (29.8 min) |
thr_fpx3vkax5h |
auto-compact-1 |
505 |
08-10 13:20:36 → 13:25:57 (5.3 min) |
thr_sdc5dy277m |
auto-compact-3 |
171 |
08-10 13:48:47 → 13:52:43 (3.9 min) |
thr_qifimqh4a6 |
auto-compact-1 |
260 |
08-10 15:08:46 → 15:14:00 (5.2 min) |
What I expected
One event bb cannot store should not stop every other thread on the machine from recording anything.
Cause
Codex labels its automatic-compaction traffic with a turn id of its own making (auto-compact-N). bb never opened that turn, so the append refuses the event with 409. The daemon holds one event queue for the whole host and reposts it as a single batch, splicing only on success — so a deterministic rejection at the head of that queue blocks every thread's events behind it, permanently.
Side effect worth noting: the queued events are dropped on restart, so affected threads have a hole in their transcripts (~4-5 minutes in most cases, ~30 in the worst).
There is also no warning. The daemon has a queue-stall tripwire, but it logs at debug, so it never fired.
Fix
PR: (linked below once opened)
All threads freeze at "waiting" until the app is restarted
Version: bb-app 0.36.0 (macOS)
What I was trying to do
Ordinary multi-thread work — several Codex threads running in parallel.
What happened
Every thread on the host stopped advancing and sat at "waiting". Nothing recovered it except quitting and reopening the app. It has now happened four times — once on 08-07 and three times on 08-10.
The server log shows one event being refused over and over:
{"level":40,"time":1786360836499,"eventType":"provider/unhandled","scopeKind":"turn", "threadId":"thr_fpx3vkax5h","turnId":"auto-compact-1", "errorMessage":"Cannot append provider/unhandled for turn auto-compact-1 before turn/started is stored", "errorName":"MissingStoredTurnStartedError","msg":"Rejected daemon event before turn/started"}505 identical rejections between 13:20:36 and 13:25:57, ending only because I killed the app. In that entire window the server logged no thread activity whatsoever — just the rejections.
Every occurrence so far, each ended by a restart rather than by recovery:
thr_dwmzmanhn5auto-compact-2thr_fpx3vkax5hauto-compact-1thr_sdc5dy277mauto-compact-3thr_qifimqh4a6auto-compact-1What I expected
One event bb cannot store should not stop every other thread on the machine from recording anything.
Cause
Codex labels its automatic-compaction traffic with a turn id of its own making (
auto-compact-N). bb never opened that turn, so the append refuses the event with 409. The daemon holds one event queue for the whole host and reposts it as a single batch, splicing only on success — so a deterministic rejection at the head of that queue blocks every thread's events behind it, permanently.Side effect worth noting: the queued events are dropped on restart, so affected threads have a hole in their transcripts (~4-5 minutes in most cases, ~30 in the worst).
There is also no warning. The daemon has a queue-stall tripwire, but it logs at
debug, so it never fired.Fix
PR: (linked below once opened)