[only21mil]

Problem

When a Muse turn is steered (Steer, or a finished delegate's result), Muse acks turn/steer only once the steer's records are on disk. On a busy disk that ack can take more than 30 seconds. The adapter sent the steer through the same 30-second request deadline as every other command, treated the late ack as a dead host, closed Muse and failed the active run. I lost a long Muse run this way: the ack came 33 seconds after the steer.

Muse Code 1.4.12 can also give up on the ack itself after 30 seconds with a -32603 error and then apply the steer anyway; the adapter failed the steer effect on that error and the server retried it, so Muse could run the same steer twice.

Change

turn/steer keeps its 30-second wait but no longer closes the host when the wait runs out. A steer still pending after the wait is reported delivered, and Muse's own "runtime command acknowledgement timed out" error is handled the same way, so the server does not retry it. Every other steer error still fails as before. Every other Muse command keeps the host-closing deadline.

Scope

Bug fix: a slow acknowledgement from a healthy Muse host kills the user's active run. There is no prior issue; this is a small, focused fix for an obvious bug, limited to the Muse adapter's steer path and its tests.

Verification

To see it on Linux web (needs a Muse login): 1. start a Muse turn that runs sleep 150; 2. delay Muse's fsync/fdatasync by 40 s with strace fault injection; 3. click Steer: on main the run fails at 30 s.

Signed in, Muse Code 1.4.15, T3 dev servers on Linux; main 0f13d2c against this head bd788bd.

Claim	main	This head
A slow steer ack no longer fails the run	Steer fails at 30.0 s, run fails	Steer reported delivered at 30.0 s, run finishes
The host stays up and Muse gets the steer once	Host gets SIGTERM, then SIGKILL, before Muse admits the steer	Muse admits the steer once, 80 s after it was sent

With Muse's -32603 answer injected by a stdio relay (main eceeab4, this head, merge 11d1ef40b9):

	main	This head, and merged with main
The steer effect	Fails on the error; T3 sends turn/steer again 139 ms later	Reported delivered; one turn/steer
Steered user messages in Muse's events	Two	One

Re-checked against main 476fc9b on 2026-11-12: its two steer tests fail there without the change and pass with it; the branch merges cleanly.

Not checked: macOS and Windows, desktop and mobile, and a server restart between a steer and its admission.

Method, why "delivered", Stop runs, more captures, trace lines, relay log, Muse's events and tests

No other provider, contract or client code changes. Every click ran in T3's Browser panel. The injected answer is Muse's own acknowledgement-timeout answer; this head was also merged locally with that main. Steer sources: a user clicks Steer, or a delegated task finishes and T3 steers its result in. Muse 1.4.12's answer in full: -32603 internal, "runtime submit failed: runtime command acknowledgement timed out after 30s"; the server retried with a fresh command id.

Stop while the ack is held:

Claim	main	This head
Stop while the ack is held	main 5d28843: Stop waits, the steer fails at 30 s, run fails	This head alone: run fails (above). Merged with main 5d28843 (948a1137fa): Stop waits for the steer, shows "Agent not responding to Stop", then ends "Stopped by user" when Muse answers

Why "delivered" is the right answer for a pending ack:

• Muse refuses a steer it will not take (missing_run, invalid_target) within milliseconds, so a refusal never reaches the deadline.
• Muse keeps an accepted steer even across a Stop and runs it as a new turn, so a late ack still means the message arrives.
• A retry is what duplicates the steer. Reporting it delivered is the only answer that cannot.

The wait stays bounded at 30 seconds because Stop and approval answers queue behind the steer effect. This change does not touch Stop. On current main, a Stop that Muse does not answer within 15 seconds shows "Agent not responding to Stop" with Force stop.

To do this, the request helper is split into send (no deadline) and request (send plus the host-closing timeout). Only the steer path calls send directly.

I ran this signed in to a Muse account in a fresh isolated home: Muse Code 1.4.15, Muse Spark 1.2 at Minimal, Full access. Each build ran as a T3 dev server on Linux ("Test machine", synthetic repo), with every click in T3's Browser panel. Builds: main 0f13d2c and this head bd788bd for the first two rows. I re-ran the Stop row on main 5d28843, on this head, and on this head merged locally into that main (948a1137fa, a local merge, never pushed). On this head as pushed, Stop still fails the run: the steer is reported delivered at 30 s, then turn/interrupt times out after another 30 s and the host is closed, because this head's base predates main's 15 s Stop change. The Stop result in the right column is from the merge. Muse runs sleep 150 and I steer it. Right before Steer, I injected a delay into Muse's own process with strace fault injection: each Muse thread's next fsync/fdatasync waits 40 s, so Muse acks the steer about 80 s late. The slow ack comes from that injected delay, not from Muse on its own.

On this head Muse later started a turn of its own ("Background activity updated", no user message) that repeated the last line. Muse got the steer once.

Muse's own acknowledgement-timeout answer. Same setup on main eceeab4, this head bd788bd, and this head merged locally with that main (11d1ef40b9, never pushed), with a stdio relay between T3 and the real Muse host. It passes every frame unchanged except one: Muse gets the first turn/steer and acks it, and the relay answers T3 with Muse's own -32603 "runtime submit failed: runtime command acknowledgement timed out after 30s" instead. That answer is injected; Muse sends it only after its own 30 s wait.

Trace lines, relay log, Muse's events and tests

Slow ack:

T3 trace, main 0f13d2c (second line: that build's Stop run; the Stop re-run on today's main is below):

$ grep steerTurn main-trace.txt | tr -s ' '
04:28:52.363Z -> 04:29:22.367Z 30003.5 ms Failure MuseAdapter.steerTurn [Muse turn/steer timed out; its host was closed.]
04:30:23.877Z -> 04:30:53.880Z 30003.3 ms Failure MuseAdapter.steerTurn [Muse turn/steer timed out; its host was closed.]

This head (lines 2 and 3: its own Stop run; its base predates main's Stop change):

$ grep -E 'steerTurn|interruptTurn' head-trace.txt | tr -s ' '
04:34:16.874Z -> 04:34:46.875Z 30000.3 ms Success MuseAdapter.steerTurn
04:38:10.290Z -> 04:38:40.292Z 30001.6 ms Success MuseAdapter.steerTurn
04:38:40.309Z -> 04:39:10.317Z 30008.2 ms Failure MuseAdapter.interruptTurn [Muse turn/interrupt timed out; its host was closed.]

Muse's events, main (no steer):

$ sed -n '2p;4,5p' main-muse-events.txt | tr -s ' '
04:28:08.449 session/started 
04:28:08.614 turn/started 
04:28:08.614 item/completed userMessage <T3 runtime preamble + user prompt>

This head:

$ sed -n '4,7p;11,12p' head-muse-events.txt | tr -s ' '
04:34:04.574 turn/started 
04:34:04.574 item/completed userMessage <T3 runtime preamble + user prompt>
04:35:36.944 item/completed userMessage steered=true HEAD-STEER-H1
04:37:37.226 item/completed agentMessage FINISHED HEAD-STEER-H1
04:39:27.211 turn/started 
04:39:30.220 item/completed agentMessage FINISHED HEAD-STEER-H1

main, strace (the test host's local clock, six hours behind the UTC lines above):

$ sed -n '1p;3p;6,8p' main-strace-M1.txt
2584141 22:28:52.366088 fdatasync(12 <unfinished ...>
2584141 22:29:32.368997 <... fdatasync resumed>) = 0 (DELAYED)
2584141 22:29:32.375379 fsync(12 <unfinished ...>
2584131 22:29:32.375718 --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=2583051, si_uid=1000} ---
2584145 22:29:34.376200 +++ killed by SIGKILL +++

Injected answer, relay log, T3 trace and Muse's events, main:

$ jq -r 'select(.method=="turn/steer") | [.t[11:23], .dir, .id, .outcome, .note // ""] | @tsv' main-relay.ndjson
22:36:09.507	t3->muse	4		
22:36:09.549	muse->relay	4	result	held back
22:36:09.549	relay->t3	4	error -32603: runtime submit failed: runtime command acknowledgement timed out after 30s	INJECTED
22:36:09.688	t3->muse	5		
22:36:09.717	muse->t3	5	result	
$ grep steerTurn main-trace.txt | tr -s ' '
22:36:09.506Z -> 22:36:09.551Z 45.6 ms Failure MuseAdapter.steerTurn [Muse turn/steer failed: runtime submit failed: runtime command acknowledgement timed out after 30s.]
22:36:09.687Z -> 22:36:09.718Z 30.8 ms Success MuseAdapter.steerTurn
$ grep steered main-muse-events.txt | tr -s ' '
22:36:09.585 item/completed userMessage steered=true MAIN-STEER-R1
22:36:12.000 item/completed userMessage steered=true MAIN-STEER-R1
$ grep -E 'effectType|attemptCount' main-effect-retry.txt
    effectType: 'provider-turn.steer',
    attemptCount: 1,

This head:

$ jq -r 'select(.method=="turn/steer") | [.t[11:23], .dir, .id, .outcome, .note // ""] | @tsv' head-relay.ndjson
22:41:56.010	t3->muse	4		
22:41:56.030	muse->relay	4	result	held back
22:41:56.031	relay->t3	4	error -32603: runtime submit failed: runtime command acknowledgement timed out after 30s	INJECTED
$ grep steerTurn head-trace.txt | tr -s ' '
22:41:56.009Z -> 22:41:56.032Z 22.5 ms Success MuseAdapter.steerTurn
$ grep steered head-muse-events.txt | tr -s ' '
22:41:56.064 item/completed userMessage steered=true HEAD-STEER-R1

This head merged with main:

$ jq -r 'select(.method=="turn/steer") | [.t[11:23], .dir, .id, .outcome, .note // ""] | @tsv' merged-relay.ndjson
22:46:48.598	t3->muse	4		
22:46:48.660	muse->relay	4	result	held back
22:46:48.660	relay->t3	4	error -32603: runtime submit failed: runtime command acknowledgement timed out after 30s	INJECTED
$ grep steerTurn merged-trace.txt | tr -s ' '
22:46:48.596Z -> 22:46:48.661Z 64.6 ms Success MuseAdapter.steerTurn
$ grep steered merged-muse-events.txt | tr -s ' '
22:46:55.304 item/completed userMessage steered=true MERGED-STEER-R1

Stop re-run with the held steer, main 5d28843 (strace lines: the test host's local clock, six hours behind UTC):

$ cat main2-revision.txt
5d28843461d5d3437436df4f3b81dc44300cd6cd
$ tr -s ' ' < main2-trace.txt
23:00:33.051Z -> 23:00:33.079Z 28.0 ms Success Orchestrator.dispatchThreadStop
23:00:32.610Z -> 23:01:02.620Z 30009.8 ms Failure MuseAdapter.steerTurn [Muse turn/steer timed out; its host was closed.]
$ grep -E 'SIGTERM|SIGKILL' main2-strace.txt | head -2
3003733 17:01:12.632868 --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=3002968, si_uid=1000} ---
3003791 17:01:14.633597 +++ killed by SIGKILL +++

This head:

$ cat head2-revision.txt
bd788bd4827ab84dd8ea6ded434bc268aa778d1b
$ tr -s ' ' < head2-trace.txt
23:03:17.115Z -> 23:03:17.134Z 18.5 ms Success Orchestrator.dispatchThreadStop
23:03:14.509Z -> 23:03:44.509Z 30000.4 ms Success MuseAdapter.steerTurn
23:03:44.525Z -> 23:04:14.534Z 30009.2 ms Failure MuseAdapter.interruptTurn [Muse turn/interrupt timed out; its host was closed.]

This head merged with main 5d28843:

$ cat merged2-revision.txt
948a1137fa9e0253be8f780129f5c906b3c8809d tree 9dcdd830672109e2b4ff42e33455eb93ad695aca parents bd788bd4827ab84dd8ea6ded434bc268aa778d1b 5d28843461d5d3437436df4f3b81dc44300cd6cd
$ tr -s ' ' < merged2-trace.txt
23:06:24.057Z -> 23:06:24.092Z 34.6 ms Success Orchestrator.dispatchThreadStop
23:06:23.763Z -> 23:06:53.764Z 30001.1 ms Success MuseAdapter.steerTurn
23:06:53.779Z -> 23:07:08.779Z 15000.7 ms Interrupted MuseAdapter.interruptTurn
23:07:08.787Z -> 23:07:08.794Z 7.0 ms Success Orchestrator.dispatchInterruptUnresponsive
$ grep -E 'terminal|steered' merged2-muse-events.txt | tr -s ' '
23:07:43.997 turn/completed terminal=cancelled 
23:08:43.741 item/completed userMessage steered=true MERGED-STOP-R2
23:08:43.742 turn/completed terminal=completed 

Tests, main with this PR's test file, then this head:

$ grep -E '^ +(×|Tests )' main-tests.txt
     × reports a steer delivered and keeps the host while Muse holds its ack 24ms
     × reports a steer delivered when Muse times out its own ack 5ms
      Tests  2 failed | 49 skipped (51)

$ grep -E '^ +Tests ' head-tests.txt head-provider-muse-tests.txt
head-tests.txt:      Tests  2 passed | 39 skipped (41)
head-provider-muse-tests.txt:      Tests  91 passed (91)

Full logs and test output: transcript

Prior PRs

• fix(provider-muse): long Muse sessions reopen instead of timing out after 30 seconds #21884 by sittingmongoose gave session/resume and session/read a longer deadline, a separate cause in the same request helper. It was closed without merging.
• fix(provider-muse): relaunch a host that died between turns #19195 by Dan Donathan (ddonathan), merged, relaunches a Muse host that died between turns. This change keeps a healthy host from being closed in the first place.

Generated with Claude Opus 5.5 in T3 Code Nightly

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

The Muse adapter separates raw RPC sending from the timeout-handling request wrapper. Turn steering uses the raw send path and handles missing acknowledgements and a specific runtime-command acknowledgement timeout differently from other errors. Tests cover steer and interrupt timeout behavior.

Changes: Muse steer acknowledgement handling

Layer / File(s)	Summary
Separate RPC sending from timeout handling packages/provider-muse/src/server/adapter.ts	The adapter adds a raw send helper. The request wrapper retains the configured timeout and timeout-triggered host failure behavior.
Handle steer acknowledgements packages/provider-muse/src/server/adapter.ts, packages/provider-muse/src/server/adapter.test.ts	steerTurn uses send and returns when no acknowledgement arrives or Muse reports the specific runtime-command acknowledgement timeout error. Other errors propagate, and received acknowledgements are checked against the active turn. Tests cover steer and interrupt timeout outcomes.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related PRs

• pingdotgg/t3code#21884: Changes per-method deadlines in the Muse request wrapper, which this PR splits into separate send and request paths.

Suggested reviewers: t3dotgg

Merge Risk: Minimal · up to bd788

The change appears mergeable after normal checks. Slow steer acknowledgements no longer fail the run, while other requests retain their timeout handling.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main fix: slow Muse steer acknowledgements no longer fail the run.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Description check		The description follows the template well. It has a clear Problem section with reproduction steps and environment, a Change section that explains the send/request split and the steer-only behavior, a …

Full details: Description check

Explanation

The description follows the template well. It has a clear Problem section with reproduction steps and environment, a Change section that explains the send/request split and the steer-only behavior, a Scope section that justifies the absence of a linked issue and calls the change a bug fix, and a detailed Verification section with observed results, what was not checked, and the model used. It also names the model and harness, as the template asks. The title is not part of this check. Some supporting detail is long and sits in a collapsed block, but the required information is all present.

Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 572cf74
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 99088009-d3e5-479e-873a-9a200d57ed32

Commits

Reviewing files that changed from the base of the PR and between 572cf74 and bd788bd.

Files selected for processing: 2

• packages/provider-muse/src/server/adapter.test.ts
• packages/provider-muse/src/server/adapter.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 2 remain after this review.

[macroscopeapp]

Approvability

Verdict: Approved at 2a545ab

Macroscope's review found this PR approvable — This narrowly scoped Muse adapter fix preserves the existing timeout behavior for all other commands while preventing delayed steer acknowledgements from closing the host or failing the run. Targeted tests cover both delayed responses and Muse’s specific acknowledgement-timeout error.

^{You can add or adjust custom eligibility rules. Learn more.}

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

@only21mil, thanks for isolating the durable-write acknowledgement timeout and keeping other errors strict. i kept both original commits and merged current main (572cf74275) into this branch. the fix retains your send/request split and narrow internal-error exception. i shortened the explanatory comments, restored the Option import removed on main, and strengthened the existing slow-ack test to cover a late response, one steer submission, and a subsequent wedged Stop closing the host.

verification on bd788bd4827ab84dd8ea6ded434bc268aa778d1b:

• both acknowledgement regressions fail with current main's adapter, including the host-closing timeout.
• all 91 muse tests pass through blacksmith. vp run check:changed passes format, lint, knip, five package typechecks, and all 41 adapter tests. scoped muse typecheck and lint also pass.
• two independent full-diff reviews found no blocking code issues. known test limit: the late-response call-count assertion precedes promise continuation processing; the SDK's maxAttempts: 1 remains the primary no-retry guarantee.
• current-main red/green and check output.

unverified: the real muse provider/client path, delayed production fsync, and the production error payload. this vm has no muse cli or production blob, so the controlled adapter tests establish t3's behavior, not the provider's eventual delivery guarantee. no client or ui implementation changed; no new app capture is claimed. @only21mil, please retain a follow-up for the documented queued-resume interaction with #24325; it does not expand this focused takeover.

ci build/typecheck, lint, web tests, all eight server shards, and the aggregate Check are green on this head. automatic CodeRabbit review completed on this head with no actionable comments. github reports the pr clean and mergeable. macroscope approval is from the original head; no fresh macroscope run was emitted.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

i ran current github/main (9b052a2d5b) in a separate worktree, stopped it, then ran exact pr head bd788bd4827ab84dd8ea6ded434bc268aa778d1b. both installs used vp i. each dev server ran in the background with isolated state, with only one running at a time. i drove the paired web app with repo playwright and /usr/bin/google-chrome.

i created a project through the app pointing at a real git repository. on the pr head, real codex gpt-6.1-sol turns verified these nearby behaviors:

• send: the provider ran sleep 75 through its terminal tool.
• steer: while that command ran, i clicked steer. the completed turn replied STEER_ACK_24326 once, replacing the original requested reply.
• stop: i started another sleep 120, clicked stop while it ran, and saw "run interrupted · stopped by user".
• follow-up: the same thread then replied RESUME_OK_24326 without resuming either command.

these are codex regression checks. they do not execute the changed muse adapter.

i inspected the captures and reopened this comment to check the screenshots. the 14-second stop recording is shared in the task thread; playback and seeking work in t3's browser, but github does not render the external mp4 inline. runtime command transcript.

Not verified

the changed muse behavior is unverifiable on this vm, not verified by the codex checks above. the vm initially had no muse executable. i installed the real public linux binary, muse 1.4.14-R7309.1, and checked its sha256 against the vendor manifest. it runs, but muse usage reports "not logged in", and a real muse exec attempt fails with "missing meta credentials". no meta credential is configured. adding muse through settings in both running apps reports zero models and asks for muse login.

i therefore could not reproduce the original timeout on main or prove the pr's delayed acknowledgement, muse's own acknowledgement-timeout error, eventual delivery without duplication, or wedged-muse stop behavior. those need an authenticated real muse account and delayed durable-write acknowledgement. no mocks, fabricated catalog, echo provider, or fixtures were used to replace that path.

native desktop, ios/android, macos/windows, delegated-task completion, and the documented queued-resume interaction were not exercised.

the existing github aggregate Check passes on this head. no new automated-check result is claimed. i made no source changes, commits, or pushes. this pass does not establish that the muse fix works end to end.

[only21mil]

Note

🤖 Claude Opus 5.5 responding on behalf of only21mil

@maria-rcks, retained. The queued-resume interaction with #24325 stays a separate follow-up and is not added to either PR.

What the interaction is, from reading both heads (bd788bd482 here, 64269818ee on #24325):

1. Muse holds a steer's ack past 30 seconds. This PR reports the steer delivered, so T3 does not send it again.
2. The server restarts before Muse admits the steer, so the steer is still queued in Muse.
3. On resume with session MCP configured, Muse replays the queued steer and the resume ack names an active turn. fix(muse): a resume that replays queued work keeps T3 tools #24325 then closes that host and resumes on a fresh one, which cancels the replayed steer.

The steer is lost while T3 has recorded it as delivered. This needs both PRs merged and a restart between the late ack and Muse admitting the steer. Each PR is correct on its own.

Not verified: no test or real Muse run has exercised this sequence. It comes from the code and matches the overlap both PR bodies describe. Your runtime note also lists it as not exercised.

My judgment, not verified: the fix belongs in #24325's relaunch path rather than here, because reporting a pending ack as delivered is what keeps a steer from running twice.

[only21mil]

Note

🤖 Opus 5.5 and Sol 6.1 replying on behalf of Victor.

Re your comment: the queued-resume overlap doesn't need a follow-up on this PR. #24325's relaunch is what cancels the replayed steer. This PR decides whether a slow steer ack lasts until a restart, and doesn't change what #24325 does on resume.

I merged #24325's head (9e25000a9e) into this PR's head (bd788bd482) locally, pushed nothing, and added one adapter test. In the first server lifetime it steers a running turn with session MCP configured, and the ack comes back either at once or after 31 seconds of held time. In the second lifetime, session/resume comes back with activeTurnId set, the way Muse replays a queued steer. The test checks that the replaying host is closed, a fresh host resumes, and nothing sends turn/steer again.

adapter.ts	Prompt ack	Held ack
main 67eebaca23 + #24325 only	replaying host closed on resume	steer fails at 30s and the host closes, as on main
main 67eebaca23 + this PR only	no relaunch	no relaunch
both	replaying host closed on resume	replaying host closed on resume

With #24325 alone, a steer that was acked promptly but not yet admitted at the restart is cancelled the same way. A held ack never reaches the restart there, because the 30-second timeout fails the steer and closes the host first. With both PRs, both ack timings reach the resume and #24325 closes the replaying host. This PR adds no state to that path. If the one-replayed-item cost needs fixing, the change belongs in #24325's relaunch. I'll correct the "Not checked" bullet in this PR's description, which says the overlap needs both PRs.

Not checked: a real Muse host, or a late turn/steer ack that arrives after the old host has closed. The fake can't show what Muse keeps of a cancelled steer. In #24325's live run, a cancelled queued user message stayed in history.

[only21mil]

Note

🤖 Opus 5.5 replying on behalf of Victor.

@maria-rcks thanks for the run; we did it with a real signed-in Muse (Muse Code 1.4.15, Spark 1.2 at Minimal, isolated login), steering a sleep 150 turn while strace held Muse's next disk sync for 40 s so the steer ack arrived about 80 s late. On main (d313b2aff3) the steer times out at 30.0 s, the host is closed and the run fails; at bd788bd482, and on this head merged with main locally, the steer is reported delivered at 30.0 s, the host stays up, Muse admits it 80 s after sending with one turn/steer call, and the reply quotes it once. A frozen host never hung Stop on any build (on current main Stop gives up after 15 s and offers Force stop, so we corrected that sentence in the description), and Muse's own "acknowledgement timed out" answer stays covered only by the adapter test because T3's 30 s wait always expired first (run summary).