Repository navigation
[Bug]: One unresponsive provider holds all four effect workers and stalls every thread #16636
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Make one provider stop answering control requests without exiting. Ours was the shared Codex app-server on Windows after it ran out of blocking threads ([Bug]: Codex app-server keeps per-thread MCP servers running after threads settle #15979, [Windows] Idle local STDIO MCP servers can exhaust Tokio blocking pool and stall the app-server openai/codex#42740); a stub provider whose
startTurnnever resolves should do the same. - Send messages to four or more threads on that provider.
- Send a message to a thread on a different provider, such as Claude.
Expected behavior
The Claude thread starts. A stalled provider fails or times out its own effects without holding up the others.
Actual behavior
Every thread stalls, on every provider. Each unanswered provider-turn.start (and later provider-turn.interrupt) holds one of the orchestration effect workers, and there are four (DEFAULT_EFFECT_WORKER_CONCURRENCY in orchestration-v2/EffectWorker.ts). Each claim has a 30-second lease, but an expired lease isn't a deadline: the effect keeps running, no worker frees up, and Claude launches, checkpoints, and deliveries wait in orchestration_v2_effect_outbox behind it. At the first lockup, four effects (three provider-turn.start, one provider-turn.interrupt) had been running for 20 to 40 minutes, long past their leases, with eleven pending behind them: five starts, four checkpoints, a steer, and a title generation. Recovery needed restarting the Codex app-server once and the T3 backend once, which interrupted every in-flight run.
Impact
Blocks work completely
Version or commit
0.0.46-nightly.20261005.2702 (first lockup) and 0.0.46-nightly.20261006.2735 (second)
Environment
Windows 11, T3 Code desktop, codex-cli 0.160.1 as the shared Codex app-server, Claude as a second provider
Logs or stack traces
orchestration_v2_effect_outbox at 12:40 PM, first lockup:
running provider-turn.start claimed 12:00:19 attempt_count 1 lease long expired
running provider-turn.start claimed 12:01:04 attempt_count 1 lease long expired
running provider-turn.interrupt claimed 12:19:26 attempt_count 1 lease long expired
running provider-turn.start claimed 12:19:40 attempt_count 1 lease long expired
pending 11 more: 5 starts, 4 checkpoints, 1 steer, 1 title generation
Codex provider log: turn/start, thread/start, turn/interrupt, thread/resume sent, never answered;
the app-server stayed alive and kept sending notifications.
For comparison, provider-turn.start normally finishes in p50 6.4 s, p95 26 s, max 33 s.
Suggested fix: give provider control effects an execution deadline that fails the run, and run each provider's effects on its own workers, so one wedged provider can't take every worker.
Activity
juliusmarminge commentedon Oct 7, 2026
Note
Grok responding on behalf of Julius.
Confirmed on current
main(517188b). One provider that stops answering can occupy every orchestration effect worker.Root cause.
Fixed pool of four workers.
apps/server/src/orchestration-v2/EffectWorker.ts:781setsDEFAULT_EFFECT_WORKER_CONCURRENCY = 4.runDaemonWithOptions(:784-853) starts that many identicalrunWorkerloops, andlayerDaemon(:857-858) uses the default.EffectOutbox.ts:314-353(claimableCandidatePredicate) only stops two effects on the same thread from running together, so the four slots are shared by every thread on every provider.No execution deadline.
runOnce(EffectWorker.ts:681-686) awaitsEffect.raceFirst(executor.execute(...), cancellation). The only other branch is an explicit cancellation, with no timeout.provider-turn.start→ProviderTurnStartService.startandprovider-turn.interrupt→ProviderTurnControlService.interrupt(dispatch atEffectWorker.ts:152-204) add no timeout either.ProviderTurnControlService.ts:194-207has a 2s deadline, but it only covers the poll afterinterruptTurnreturns.client.request("turn/start", ...)(CodexAdapterV2.ts:5890) and thethread/start/thread/resumerequests (~:6079-6110) are unbounded.packages/effect-codex-app-server/src/client.tshas no default request timeout.timeoutOption("10 seconds")around waiting for completion (:6550,:6624). The bareturn/interruptrequest at:6561is not.The lease is never enforced while the process is alive.
claimNext(EffectOutbox.ts:518-552) writeslease_expires_atbut only claimsstatus = 'pending'rows (:324).lease_expires_atwith the current time, and there is no renewal or reclaim of expired leases.runningrows are only handled byreconcileAfterProcessLoss(:483-512) on the next server start.workerIdis per process (EffectWorker.ts:538), so the ownership checks insucceed/fail/retrystill pass long after the lease has expired.In practice the 30s lease is metadata only. A fiber blocked on a silent provider holds its slot until that provider answers or the server restarts, which matches the outbox snapshot in the report.
Suggested fix direction. Both parts from the report seem right, and they work independently:
provider-turn.start(~33s) or derive it from the lease and renew the lease while the call is healthy. On timeout, interrupt the fiber so its slot frees up, and settle the run through the existing retry/fail path.A unit test with a stub executor whose
provider-turn.startnever resolves, plus four or more threads, would reproduce this deterministically.Related.
startingforever afterprovider-turn.startexhausts its retries — no Stop button, settle refused, only Delete clears it (Pi provider, desktop) #13392 (closed) and Run stays "starting" when its thread's recovery state can't be read #16441, which cover runs stuck instartingwith different triggersI didn't find an open PR that adds a deadline or per-provider lanes.
krivenkop commentedon Oct 18, 2026
Note
Claude Opus 5.5, an AI agent in Claude Code, writing on behalf of @krivenkop. Diagnosed from
statev2.sqliteand the server log on their machine.Another occurrence on 0.1.0 (Linux,
t3 serve), and in our case no Codex involved: every stuck effect was on a Claude Agent provider instance (through a local Anthropic-compatible proxy that kept answering normally; it served only 46 short requests during the stall, all 200 under 10 s).Timeline (UTC, 2026-10-18), from
orchestration_v2_effect_outbox:environment api request failedwitherrorTag: 'Interrupt'at 00:40:59. At 03:37:32 everything drains at once: dozens of queuedthread.auto-settleattempts fail with "changed before automatic settlement".ProcessRunner's timeout return, leaking aVcsProcesspermit; after 8 leaks every git call and every new turn hangs forever #20419.provider-turn.starteffects finished in under 15 s; the other 6 are the rows above. So a deadline on the effect itself, not only on the lease, would separate these cleanly.The trigger seems to be a run cancelled or interrupted right before (thread A run cancelled at 00:27, steer/interrupts from an automation client). After that, the next start on the same thread never resolved until a worker freed up.
Workaround we run meanwhile: a watcher that reads the outbox every 15 s. It alerts on any effect pending or running for more than 15 s (checkpoint: 60 s). After 30 s more it kills the Claude CLI process of that thread, matched via
--session-idinprovider_threads, so the start fails and frees its worker.josephv123 commentedon Oct 18, 2026
Note
Claude Opus 5.5 in Claude Code, writing on behalf of @josephv123.
Another occurrence, Claude only, on nightly
0.1.1-nightly.20261018.3315(Linux). Here the blocking call is identified.Twelve Claude threads had stalled while their agents slice was throttled at
MemoryHigh(theclaudeprocesses were alive but barely running). Stop was sent to all 12 at 13:41:22. From the trace andorchestration_v2_effect_outbox:provider-turn.interrupteffects were queued within about a second.preview.cleanup/terminal.cleanupeffects for those threads waited 217–219 s behind them. They normally take about 0 s.The time was spent in
ClaudeAdapterV2.interruptTurnawaitingexisting.query.interrupt, the SDK's interrupt control request. That call has no deadline: the SDK resolves it only when the CLI sends itscontrol_response. The existing 10 s bound covers only the close that follows. Each of the four spans ended exactly 2.0 s, the SDK's close grace, after its CLI finally answered. Those CLIs had been silent for up to 369 s.#21303 bounds that one call and always continues to the close, so Stop ends the turn as
interrupted. It combines #16419 and #16439 on currentmain. In a live check with aSIGSTOPped real Claude CLI, theinterruptTurnspan went from 90.7 s (it only ended afterSIGCONT) to 12.0 s, and the frozen CLI was killed 17 s after Stop. It doesn't touch the worker pool itself, so it fixes one source of this stall, not the issue.fix(server): Stop no longer hangs on a frozen Claude CLI
josephv123 commentedon Oct 22, 2026
Note
Claude Opus 5.5 in Claude Code, writing on behalf of @josephv123.
Reproduced on the current nightly,
0.1.2-nightly.20261021.3499on Linux (t3 serve, default four effect workers), with the outbox snapshot and server log taken while it was stuck: secret gist (outbox-snapshot.txt,server-log.txt, plus the trace spans and the stub).Setup: a Codex instance whose app-server stays alive but never answers
thread/start(a small proxy in front of codex-cli 0.163.0 that drops it,codex-wedged.jsin the gist), four Codex threads, then one Claude thread, on a separate server with a throwaway home.provider-turn.start: queued at 13:29:27.885Z, attempt count 0.provider-turn.starton Codex threads, claimed at 13:29:20.093, 13:29:21.014, 13:29:21.912 and 13:29:22.803Z. At the snapshot (13:39:56Z) they were 636, 636, 635 and 634 s old, about 605 s past their 30 s leases, with attempt count 1.Each of the four was blocked in a single
CodexAppServerProtocol.request(thread/startunderProviderTurnStartService.loadFromProvider). Each span ran about 639 s and ended only when I killed the app-server at 13:39:59.533Z. Nothing timed out or reclaimed the expired leases in the meantime. The Claude start was claimed 18 ms later (13:39:59.551Z), 631.7 s after it was queued, and its turn then completed normally (checkpoint captured at 13:40:03Z).nadam54321 commentedon Oct 24, 2026
Same here on T3 0.1.1 (
t3 serve) with Codex 0.162.1, in a Linux VM with 4 GB and no swap. From about 15:30 UTC on 23 October fourprovider-turn.starteffects went to running and stayed there; their leases expired and were never reclaimed, so 55 turn starts and 53 title generations waited behind them, and no turn finished on any thread until we stopped the runs and restarted T3 at 21:52 UTC.The trigger was the agents slice holding at MemoryHigh (2.0 GB of 4 GB): 3.6 million high events, 96% of its time stalled, Codex's threads in
__mem_cgroup_handle_over_high, while the VM had 846 MB free. In the slice were the app-server with about 38 loaded threads, most waiting on command approvals, and 31 processes of one MCP plugin, about 78 MB each.Adding swap (Ubuntu's zram) has kept the slice from stalling since, even with 30 turns waiting on approvals at once. It only removes this trigger: the four workers never freed themselves, so any provider that stops answering can still stall every thread.
seankoji commentedon Oct 27, 2026
Additional live Linux incident evidence from 28 October 2026 (AEDT, UTC+11).
A read-only pre-recovery inspection of the backend found all four default effect-worker slots occupied by
provider-turn.start. Their associated threads were configured for Codex. OpenCode threads and later control/cleanup work were also stuck.All four leases had expired and their owner matched the backend PID in runtime metadata. In the same inspection window, the outbox held 29 pending
provider-turn.interrupt, 82provider-session.detach, 12 further starts, 30 delegated stops and 4 checkpoints. The installed server bundle setsDEFAULT_EFFECT_WORKER_CONCURRENCY = 4.The saved incident sequence was stalled existing threads, acknowledged Stop requests that did not clear them, and later threads accepted without provider progress. Reconnecting the desktop did not clear it. A targeted Stop later interrupted one parent, but another queued Codex start immediately occupied the freed slot and stalled. That makes clearing one parent insufficient to clear the shared backlog. Saved histories and Git work were preserved; recovery is being handled separately.
Environment and limits:
0.1.3-nightly.20261026.3726; its activation receipt records sourcee900e620238baa804cf487efb21fe659ca9a189b. Runtime metadata separately reportsserverVersion: 0.1.2. I have not reproduced on an unmodified current build.This appears to be another occurrence of #16636. The initiating provider failure and a permanent fix remain unverified. A separate, approved same-runtime restart is being attempted for recovery; this comment does not claim its outcome.
Reported through Codex, GPT-6.1 Sol at xhigh effort.
piotrnowakowski commentedon Oct 29, 2026
Note
Claude Opus 5.5 in T3 Code, writing on behalf of @piotrnowakowski. Diagnosed from
statev2.sqliteand the provider/server logs on their machine.Three more occurrences on Windows 11, T3 Code desktop 0.1.3, shared Codex app-server codex-cli 0.165.0, Claude Agent as the second provider. All three were triggered by an orchestrator fanning out Codex delegates via
delegate_taskin waves of five.Every time, exactly four Codex
provider-turn.starteffects were claimed (attempt_count = 1) and never finished. Everything after them stayed pending withattempt_count = 0, on every provider, until the app was restarted and the restart cancelled them.provider-turn.startcheckpoint.capture, 1thread-title.generateprovider-turn.startprovider-turn.startprovider-session.detachFor comparison,
provider-turn.starton the same day before the stall: 286 effects, mean 4.1 s, max 48 s.From the user's side, a Claude thread showed the sent message plus the "thinking" indicator for 30 minutes. Its
provider-turn.startwas never claimed, and its provider log has nothing between the previous turn and the restart.What the Codex app-server did (29 Oct, shared session log)
The app-server was not fully wedged. Only the four new turns hung:
So T3 kept talking to the app-server normally. The four workers stayed blocked on four
turn/startcalls that never returned, with no deadline.Each new Codex thread starts about 15 MCP servers from
~/.codex/config.tomland plugins. Six of them are local stdio: playwright, node_repl, cua_repl, blender, mlflow and openai-api-key-local-confirmation. In the stalled wave, several were still failing or timing out whileturn/startwas pending:mlflow"timed out awaiting tools/list after 60s" (final status at 22:26:13),playwright"timed out awaiting tools/list after 30s", plus auth failures for two remote ones. Every MCP server had reached ready or failed by 22:26:13, but the fourturn/startcalls still never returned. This may be related to openai/codex#42740 (Windows stdio MCP servers exhausting the blocking pool), but I could not confirm it from the logs. Unlike that issue, the app-server here kept answering other requests.Either way, the T3 side matches this issue: one provider's hung
turn/startblocks all four shared effect workers, and that stalls Claude threads too. A per-effect deadline onprovider-turn.start, or per-provider workers, as proposed in #23854 / #21321, would have contained all three incidents.Workaround on our side for now: disable rarely used stdio MCP servers in
~/.codex/config.toml(enabled = false), and restart T3 when every thread stalls.ethanjnrg commentedon Oct 30, 2026
Additional observed occurrence on macOS arm64 (27.0.1), T3 Code Beta 0.1.5, on 2026-10-30. Diagnosed read-only from the local run projection, effect outbox, server trace and installed application bundle. The currently installed Codex CLI reports 0.166.0; I have not independently established the exact executable/version of the earlier stalled app-server.
This corroborates the unbounded provider-control request portion of this issue. I did not establish exhaustion of all four workers or a cross-provider outage.
Observed sequence (UTC)
CodexAppServerProtocol.requestbegan underCodexAdapterV2.resumeThread.Interrupted, after 19,334,593.133 ms (5h 22m 14.593s).The UI appeared to be working throughout, but the run projection has
startedAt: nulland the final activity saysRun interrupted before provider start. This was a stalled startup operation, not five hours of model execution.The matching
orchestration_v2_effect_outboxrow records:The nested
ProviderTurnStartService.startspan lasted 19,334,600.559 ms, also ending as interrupted. No automatic timeout/failure/retry settled this attempt during that interval. Later user messages started and completed normally; this report does not claim a restart was necessary or identify what restored the transport.Installed-source check
In the shipped
apps/server/dist/binCli-1k0PQRR7.mjs:CodexAdapterV2.resumeThreadcallsclient.raw.request("thread/resume", { threadId, excludeTurns: true, ... })and awaits it without a local timeout.CodexAppServerProtocol.requestregisters a pending deferred, offers the outgoing request, then awaits the deferred with interruption cleanup, but no request deadline.DEFAULT_EFFECT_WORKER_CONCURRENCY = 4.The fact that
excludeTurns: trueis already present distinguishes this from the older full-history resume response problem in #6399.Scope / uncertainty
This is one live observation, not a deterministic reproduction. I have not reproduced it with fault injection. The exact reason the resume request did not complete is unknown: these records do not prove an app-server exit, stdio backlog, OOM, provider usage limit, or four-worker saturation. #24300 is related to unanswered shared app-server control requests, but its backlog diagnosis has not been established here.
The confirmed containment gap is that a provider-control RPC remained pending for over five hours before manual cancellation, with neither a visible startup error nor bounded recovery. A deadline on the startup/control operation would contain this case even if the initiating transport/provider failure remains unknown.
Reported by Codex (GPT-6.1 Sol) at the user's explicit request. Conversation content, business data, local identifiers and credentials are omitted.
esukram commentedon Oct 31, 2026
Note
AI-generated report. Written by Claude Opus 5.5 (Claude Code, run through
t3 triage) on behalf of @esukram. Diagnosed read-only fromstatev2.sqlite, the server trace, the provider event logs and Codex's ownlogs_2.sqliteon their machine. A human reviewed it before posting.Another occurrence on
0.1.6-nightly.20261030.3940(Linux,t3 serveas a systemd user service, codex-cli 0.166.0 as the shared app-server, Claude Agent as the orchestrating provider). It adds two things to this issue: the trigger that wedged Codex, and a second blocking path, the per-worktree workspace lease, that stalls Claude runs before the worker pool is exhausted.Trigger: Codex drops its stdio client on EAGAIN but keeps running
Codex's own log (
~/.codex/logs_2.sqlite) at the moment it went silent:/proc/<pid>/fdinfo/1showsflags: 04002, i.e.O_RDWR|O_NONBLOCK.futex_do_wait, so T3 never noticed.thread/start(ids 10, 15, 16),thread/unsubscribe(ids 11–13) andturn/interrupt(id 14) from 17:45 to 18:09. Nothing came back.codex exec --jsonpanics with "failed printing to stdout: Resource temporarily unavailable (os error 11)" when the stdout reader is slow openai/codex#55242 (codex exec --jsonpanics on the same EAGAIN when the stdout reader is slow).Second blocking path: the workspace lease
ProviderTurnStartService.startwraps startup inwithWorkspaceLease(worktreePath, …). That is a per-pathSemaphore(1), shared with git workflow ops, terminal open and checkpoint rollback.A
delegate_taskchild inherits the parent's worktree. So a Codex delegate whosethread/startnever returns holds the parent's worktree lease indefinitely. In this case:provider-turn.startthread/startid 10, holding W1's leaseprovider-turn.startstarting, three more runsqueuedbehind itprovider-turn.startprovider-turn.startlease_expires_atNULL.ProviderTurnStartService.startchild span (not evenprepareRetryHandoff) completed for the blocked Claude start.Recovery
systemctl --user stopon thet3code-codex-*.scope, with no T3 backend restart:Suggestions (beyond the deadline and per-provider workers already proposed here)
Environment
0.1.6-nightly.20261030.3940(triage CLI 0.1.6),t3 serveundert3code.service; client is the web UI against the LAN serverclaude-opus-5-5Model: Claude Opus 5.5. Harness: Claude Code. Orchestrator: T3 Code (
t3 triage).esukram commentedon Oct 31, 2026
Note
AI-generated follow-up. Written by Claude Opus 5.5 (Claude Code, run through
t3 triage) on behalf of @esukram. It follows up on the comment above. Evidence comes from host monitoring (Dynatrace OneAgent, plus T3's own OTLP metrics), a cgroup watcher, the local trace and Codex'slogs_2.sqlite. A human reviewed it before posting.Same machine, same build (
0.1.6-nightly.20261030.3940, codex-cli 0.166.0). The wedge recurred twice more after recycling the Codex app-server: three times in ~80 minutes (17:29, 18:30, 18:51 UTC). Each time the cure was the same: stop thet3code-codex-*.scope. Every occurrence was a Codexdelegate_taskchild of the same Claude orchestrator thread, sharing its worktree.Ruled out
t3_server_event_loop_delay_max(T3's own OTLP metric, 1-min max) was 15 ms at 17:29 and 13 ms at 18:30, never above 38 ms from 17:20 to 18:42MemoryHighonapp-t3code-agents.slice)memory.events:highandsock_throttledflat for >5 min before the 18:51 EAGAIN, memory PSIsome avg10=0.00, slice at 7.7 of 9.4 GiBThe 18:51 occurrence logged the same
Failed to write to stdout: Resource temporarily unavailable (os error 11)as the first. The process stayed alive and dropped every later message.Likely mechanism: T3 stops reading Codex's stdout while waiting on its own lock
The reader in
packages/effect-codex-app-server/src/protocol.ts(~L406–430) processes stdout one line at a time and handles each line before pulling the next chunk.handleNotification→options.onNotification→client.tsdispatchNotification→ the adapter handlers.CodexAdapterV2.ts, theitem/started,item/completed,thread/closedandthread/goal/*handlers all run underturnTerminalizationPermit.withPermits(1)(e.g. ~L4528, L4694, L4835, L5157). That is oneSemaphore(1)per adapter session, and with the shared app-server that means one for all Codex threads.item/agentMessage/deltastream, Codex then fills its (non-blocking) stdout socket, gets EAGAIN, and treats the client as gone.This matches every measurement above: idle host, healthy event loop, and EAGAIN mid-stream. I have not identified which permit holder waits.
turn/interruptpath (~L4511), but that request isforkIn(scope)and doesn't hold the permit.Timing correlation
dropping messageat 18:30:55.494,RunFinalizationService.finalizeat 18:30:55.868. At 18:51, finalize (18:51:26.978) falls inside the 10 s window of the EAGAIN.Version history on this machine
0.1.6-nightly.20261029.38920.1.6-nightly.20261030.3940(Oct 31, 02:09)3892...3940has 71 commits. None touches the protocol reader, butCodexAdapterV2.tsgained the generated-image state (#19066, +119 lines). Load also differed, so this is not proof of a regression.Suggestions
turnTerminalizationPermitacross an RPC or I/O wait.Side note: the server's OTLP trace and metric export to the collector stopped at ~18:43–18:45 UTC, while local
server.trace.ndjsonkept writing. Possibly unrelated.Model: Claude Opus 5.5. Harness: Claude Code. Orchestrator: T3 Code (
t3 triage).esukram commentedon Nov 1, 2026
Note
AI-generated update. Written by Claude Opus 5.5 (Claude Code, run through
t3 triage) on behalf of @esukram. A human reviewed it before posting.This still happens on
0.1.7-nightly.20261031.4004with codex-cli 0.166.0. On Nov 1 at 13:25:29 UTC the shared Codex app-server loggedos error 11on stdout, then went silent. Two Codexdelegate_taskstarts (thread/startids 27 and 32) were never answered, holding 2 of the 4 workers until we stopped thet3code-codex-*.scopeby hand. So it isn't specific to20261030.3940.The likely cause on T3's side, Codex notification handlers stalling the stdout reader, is now tracked separately in #28697.
Model: Claude Opus 5.5. Harness: Claude Code. Orchestrator: T3 Code (
t3 triage).dellintosh commentedon Nov 4, 2026
Note
AI-generated follow-up. Written by Claude Opus 5.5 (Claude Code) on behalf of @dellintosh, from the server trace, the service log,
statev2.sqlite(read-only) and Codex'slogs_2.sqlite. A human reviewed it before posting.Same wedge on the stable v0.1.6 release, on Linux, headless. Adding it because the setup differs from the Windows reports here, and the effect outbox shows the four-worker hold directly.
Environment: Ubuntu 26.04.1 LTS (kernel 7.0.0-38),
t3 serveas a systemd user service, t3 v0.1.6, codex-cli 0.166.0 as the shared app-server, Claude Code 2.1.318 as a second provider. About ten threads across two projects, several of them Codexdelegate_taskchildren.What happened (UTC, 2026-11-04):
provider-turn.starteffects were claimed (attempt_count 1). At least two were Codexdelegate_taskchild starts.thread/resume(request 253) andthread/start(request 254) arriving. Its last line of any kind is at 02:59:10, then nothing until the restart at 10:44. No error and no exit message.orchestration V2 provider event ingestion failedwarnings (RunExecutionIngestError, caused byProviderAdapterEventStreamErroronprovider-session:provider-instance:codex:shared, caused byProvider session released: idle_timeout), thenorchestration-v2.provider-session-scope-close-timeout30 seconds later.startingtoo. Effects created later (another Codex start, a title generation, a delegated-task stop) stayed at attempt_count 0.t3code-codex-*.scopeno longer held a codex process (only an unrelated dev server an agent had started), yet the four starts still held their workers. So the hold outlives the provider process, not only a live but silent one.Recovery:
t3 service restart. The four held starts and the queued one endedcancelled("Cancelled because the server shut down before the provider work completed."), and the queued title and stop effects ran within seconds. Claude threads resumed by themselves; Codex threads came backcancelledand needed their last message resent.Outbox rows (read-only query):
I checked the v0.1.7 release notes and found nothing aimed at this. The open PRs #23854, #21321 and #28711 look like the fixes.
Model: Claude Opus 5.5 via Claude Code.