feat(provider-muse): Auto mode uses Muse's own auto-review#23236

Approvability

Verdict: Approved at 2078a7a

Macroscope's review found this PR approvable — Muse Auto mode is now explicitly exposed and mapped to Muse’s native auto-review profile, with existing Supervised and Full access behavior preserved. The default permission remains unchanged, and the server-side mapping is covered by focused tests.

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

Review in Change Stack →

No actionable comments were generated in the recent review.

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

External image Recent review info

External image Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 6262c9a
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 1fce559c-8076-4ab7-aebf-4e3d4834f6ba

External image Commits

Reviewing files that changed from the base of the PR and between 2078a7ab1c0bcda6477365576688fbea79c82157 and 54a0ef27f571e63f5924fbaac90e5c2e9809dca2.

External image Files selected for processing: 4

• docs/user/permission-modes.md
• packages/provider-muse/src/server/adapter.test.ts
• packages/provider-muse/src/server/sdk.ts
• packages/provider-muse/src/server/status.ts

Limit details: You’ve used all 10 included reviews currently available.

Merged current main into this head with a merge commit and resolved the permission documentation, SDK mapping, and supported-mode conflicts. Muse Auto still selects :auto-review with promptUnmatched; Supervised and Full access retain their behavior. Main's fx guidance and shorter comments are preserved. The diff remains five files (14 additions, 12 deletions).

Blacksmith vp run check:changed 6262c9a2ba51fec145bf3efd35126ce72739a8be passed formatting, lint, both knip checks, typechecks for 10 affected packages, and all 60 selected tests. Two independent code reviews found no actionable defects. GitHub reports no merge conflicts at 54a0ef27f571e63f5924fbaac90e5c2e9809dca2.

Native Muse start/resume and switching an existing thread to Auto remain unverified on this VM because Muse and its login are unavailable. The existing adapter test covers the requested profile on both start and resume. CI is running on the pushed merge commit.

Verified in a real dev environment

partial verification at 54a0ef27f571e63f5924fbaac90e5c2e9809dca2, compared with github/main at 7195b69954 on linux. dependencies were installed with vp i; each build ran through vp run dev, one server at a time. playwright drove /usr/bin/google-chrome.

i created a real git repository and added it as a project through the app. real codex gpt-6.1-sol turns completed on main and after resuming on the pr build, ran git commands, and reported the clean worktree. no mocks or replay data were used.

muse code 1.4.14 was installed from its published linux artifact and checksum-verified. with no login it returned no models, so i configured its documented muse-spark-1.3 model through settings and created a real muse thread through the running server cli. its logged-out turn failed, but the existing thread exposes the real permission controls.

• main: muse offers supervised and full access, with no auto.
• pr: muse also offers auto. selecting it persists after reload. switching among full access, supervised, and auto updates the controls.
• sending from the web client in auto reaches the real muse process. muse rejects session/start with permission profile :auto-review cannot be used: the automated reviewer is unavailable on this host. this proves the requested native profile reaches muse; it does not prove successful review.

blacksmith vp run check:changed 6262c9a2ba51fec145bf3efd35126ce72739a8be passed format, lint, both knip checks, 10 package typechecks, and all 60 selected tests. github ci also passes on this head. no source changes were made.

main: muse permission menu has two modes

pr: the same muse thread also offers auto

pr: the real muse process rejects auto-review without its reviewer

pr: real codex turns complete before and after server replacement

pr: switching muse modes and submitting auto to the real provider

Not verified

successful muse auto-review remains blocked by the missing muse account login and native reviewer. i could not verify which actions it approves, escalation to human approval, successful native start/resume, or inherited auto in a real muse delegate. supervised execution also remains blocked by login. codex success does not substitute for these muse checks.

native desktop, ios/android, macos/windows, remote relay/tunnel connections, and muse api-key setups were not exercised. this is partial evidence, not a full end-to-end approval of muse auto mode.

i desparately need this feature so that i could have claude delegate muse subagent with auto permission; begging for this thread to gain more attention.

@busFred thanks. The PR is up to date with main and its checks pass. maria's run on 2026-11-01 confirmed that Auto shows up for Muse and sends Muse's :auto-review profile. What's still untested is a successful auto-review with a signed-in Muse account. After that, it's waiting on maintainer review.

Does someone has to contribute his or her account for this to pass? If so, I'm more than happy to contribute my account for this.

Note

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

@busFred thanks. The PR is up to date with main and its checks pass. maria's run on 2026-11-01 confirmed that Auto shows up for Muse and sends Muse's :auto-review profile. What's still untested is a successful auto-review with a signed-in Muse account. After that, it's waiting on maintainer review.

@busFred thanks for the offer. No one needs to share an account. We signed a test machine into one of our own Muse Code accounts and ran the branch at 54a0ef27.

With a signed-in account, Muse's own auto-review makes the approval decision. In a Muse thread set to Auto, I asked Muse to add a function to math.ts and run git diff --stat. It edited the file and ran the command, and T3 Code showed no approval prompt. Muse's trace shows its own reviewer approving the command:

Muse's session record shows the profile T3 Code sent: {"display_name":"Auto-review","id":":auto-review","kind":"built_in"}.

main: a Muse thread offers Supervised and Full access.

main: Muse permissions offer Supervised and Full access

This PR: Auto is offered for Muse.

This PR: Auto selected for a Muse thread

This PR: the Auto turn edits the file and runs git diff --stat with no prompt.

This PR: Muse Auto turn with no approval prompt

One Linux caveat: Muse runs approved commands inside its own sandbox. On a host where that sandbox can't start (we hit this on Ubuntu 26.04, which restricts unprivileged user namespaces), Muse still auto-approves the first command. It then asks a person before rerunning that command outside the sandbox, so you'd see approval cards. That prompt comes from Muse, not T3 Code. The run above was on a Linux machine where the sandbox works.

Still untested: a Muse subagent delegated from another provider and inheriting Auto (your Claude → Muse case), macOS and Windows, and Muse API-key setups.

Your own test would help most on the delegate case. If you can, check out r13/a077-offer-auto-mode-using-muse-s-auto-review from only21mil/t3code, run it with your own Muse login (vp i, then vp run dev), have Claude delegate to a Muse subagent in Auto, and post what you see here.

@only21mil ran the delegate test you asked for. A Claude → Muse subagent in Auto inherits Auto, and Muse's own auto-review approves its commands with no T3 Code approval card. This held with both an API-key login and a subscription login.

Setup

• Branch r13/a077-offer-auto-mode-using-muse-s-auto-review at 54a0ef27, run with vp run dev from a separate clone with its own T3 data folder.
• Linux, Node 26.12.1, Muse Code 1.4.14.
• A Claude Haiku 5.5 thread set to Auto called delegate_task to start a Muse child (Muse Spark 1.3, low effort). The child created a small .ts file and ran git diff --stat and git status --short.
• I read the results from Muse's own session logs, not only from the Claude thread's summary.

Results

So the API-key setup works too, not only a signed-in account.

Excerpt from Muse's session record (session.jsonl) for the subscription run, trimmed and paraphrased from the JSON records:

@busFred thank you, this settles the two cases we couldn't check. A Muse child delegated from a Claude thread in Auto inherits Auto, gets the :auto-review profile, and Muse's own reviewer (llm_judge) approves its commands with no approval card in T3 Code. Your runs show that holds with an API-key login as well as a subscription login. Reading the results from Muse's session logs, not just the Claude thread's summary, makes this a direct check of what Muse decided. The PR description still guesses that Auto may fail to start on API-key setups; that's now out of date, and I'll correct it and credit you. Your runs were on Linux, so macOS and Windows stay untested.

Anything else that needs to do for this to make the next release? If so, what can I do to speed things up and get it merged?

Note

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

@busFred thank you, this settles the two cases we couldn't check. A Muse child delegated from a Claude thread in Auto inherits Auto, gets the :auto-review profile, and Muse's own reviewer (llm_judge) approves its commands with no approval card in T3 Code. Your runs show that holds with an API-key login as well as a subscription login. Reading the results from Muse's session logs, not just the Claude thread's summary, makes this a direct check of what Muse decided. The PR description still guesses that Auto may fail to start on API-key setups; that's now out of date, and I'll correct it and credit you. Your runs were on Linux, so macOS and Windows stay untested.

@busFred nothing else is open on our side. Every check passes on the current head (54a0ef2), the branch merges cleanly with main, and no review threads are open. What's left is a maintainer review. Merging, and which release it ships in, are the maintainers' call, so I can't promise a date.

If you want to help, the gap is coverage we don't have: an Auto run on macOS or Windows, or with Muse set to use another model provider. If you try either with your own setup, a short note here with what Muse's log showed would add to the PR. Nobody needs to share an account or credentials.

@only21mil ran the Windows check. On Windows 11, Muse's own auto-review approves an Auto session's command with no request sent to the client, and the :ask-me control sends one. This was a subscription login, and I drove Muse through the branch's own launch code, not through the T3 Code UI.

Setup

• Branch r13/a077-offer-auto-mode-using-muse-s-auto-review at 54a0ef27, in a fresh clone.
• Windows 11 (10.0.26300), Node 24.21.0 (the repo pins 26.12.1), pnpm 12.14.0, Muse Code 1.4.14.
• Signed in with muse login (device-code browser flow). muse usage reports the Muse Code Power tier.
• A throwaway vitest file, deleted afterwards, calls the branch's museLaunch, museServeArgs, createMuseSdkHost, museApprovalMode and musePermissionProfile. It starts session/start, sends one turn/start, and logs every notification and server request. The turn asked Muse to run Get-ChildItem -Name with its shell tool, in an empty temp folder.
• I read the results from Muse's session.jsonl, not only from the harness output.

Results

Excerpt from Muse's session record for the Auto run, trimmed from the JSON records:

Not covered

• Muse set to another model provider, and macOS.

Follow-up to my Windows run: I also checked the branch through the T3 Code UI on Windows 11 (head 54a0ef27, Muse Code 1.4.14).

• In a Muse thread, the permissions menu offers Supervised, Auto and Full access. Selecting Auto shows "Auto" in the composer.
• I sent a read-only prompt (Get-ChildItem -Name) in an Auto thread on Muse Spark 1.3. Muse's session log shows the :auto-review profile, automated_review_completed with status: "approved" and risk_level: "low", and decision_applied with decision_source.kind: "llm_judge". T3 Code showed no approval prompt.
• The command itself did not run: Muse returned setup_required: windows elevated sandbox setup has not run for the shell tool, so the thread ended without output.

@busFred thank you for both Windows runs. They're the first Windows coverage this PR has.

• The profile makes the difference. With the branch's own launch code on Windows 11, cmd.exe starts muse.cmd and session/start succeeds. The :ask-me control sent approval/request to the client. :auto-review sent nothing, and Muse's reviewer (llm_judge) approved the command.
• Through the T3 Code UI. A Muse thread offers Supervised, Auto and Full access. In an Auto thread, the reviewer approved Get-ChildItem -Name and T3 Code showed no approval prompt, which is what this PR is for.
• The command not running. setup_required: windows elevated sandbox setup has not run comes from Muse. Its Windows sandbox hadn't been set up on that machine. Muse's log shows the approval applied first, so the refusal doesn't depend on Auto. It's a Muse setup step, not something T3 Code or this PR controls. T3 Code shows a failed Muse tool call as a failed command, with Muse's reason in its title and output, and a failed turn as an error. That code is the same on main and this branch. If the thread showed nothing at all for that call, a screenshot would help us check.

I'll add both results to the PR description. Still untested: a command that actually runs under Auto on Windows once Muse's sandbox setup has run, a Claude → Muse delegate and an API-key login on Windows, Muse set to another model provider, and macOS.

@only21mil here is the screenshot you asked for. The thread does show the failed call: T3 Code lists Get-ChildItem -Name as its own row under "Worked for 22s", and the row carries Muse's reason (environment failure: sandbox enforcement unavailable: windows_elevated setup_required: windows elevated sandbox setup has not run), followed by the assistant's message.

I reran the same Auto prompt on a fresh checkout of 54a0ef27 with the dev server started in a separate process. Muse's log again shows the reviewer (llm_judge) approving the command before the same refusal.

One correction to the note above: on this machine muse sandbox windows check reports status=ready, so I can't say the sandbox setup simply hadn't run.

@Yash-Singh1 @maria-rcks @t3dotgg could one of you review this PR when you have a moment? It looks ready on our side.

What it fixes: a Muse thread set to Auto currently runs as Supervised, so a Muse delegate that inherits Auto from its parent waits on every command approval until someone opens it (#20739). This PR sends Muse's own :auto-review profile for Auto and lists Auto in Muse's supported modes. Supervised and Full access are unchanged.

State at 54a0ef2: 5 files (+14/−12), all checks pass, merges cleanly with main, and Macroscope and levochkaa have approved.

Evidence so far

• Linux, through the T3 Code UI: Auto is offered for Muse, and the reviewer approves commands with no approval prompt (only21mil's run above).
• Linux, Claude → Muse delegate in Auto: the child inherits Auto, with both an API-key login and a subscription login.
• Windows 11: Muse started through the branch's launch code, :ask-me sends approval/request and :auto-review does not, and the reviewer approves the command through the UI as well.

If there is a specific check you'd like before reviewing, tell us which. We can try it on Windows or Linux, but we have no macOS machine.

@busFred thanks for the screenshot, the rerun on a fresh checkout, and for correcting my guess.

• The failed call shows up. The screenshot answers what I asked: T3 Code gives Get-ChildItem -Name its own row with Muse's full reason, then the assistant's message. Nothing is lost in the UI.
• I had the cause wrong. I said Muse's Windows sandbox setup hadn't run on that machine. Since muse sandbox windows check reports status=ready, that isn't it, and I'll correct the PR description. Why Muse's shell tool still reports windows_elevated setup_required under T3 Code is open.
• What this PR touches. It doesn't change how T3 Code starts Muse. Supervised and Auto both run muse serve --trust-workspace with Muse's sandbox on, and only Full access adds --disable-sandbox. T3 Code passes Muse the server's environment, minus META_API_KEY. Muse's log shows the approval applied before the refusal, so the refusal doesn't come from Auto.

If you get a chance, the same prompt in a plain muse terminal session would show whether the refusal also happens outside T3 Code. No need if you're busy, and thanks for asking the maintainers for review.

@only21mil I ran the check you suggested, and the refusal also happens outside T3 Code. This used a plain muse exec run, not the interactive terminal UI, on Windows 11 with Muse Code 1.4.14 and a subscription login.

Muse's powershell tool call failed before the command started:

• Same failure, different wording. T3 Code showed windows_elevated setup_required: windows elevated sandbox setup has not run. Plain Muse reported the deny_read_acl_state.json / ACL message above. Both are Muse's Windows sandbox refusing to start the shell.
• So it isn't T3 Code or this PR. The same Muse binary, profile and machine fail without T3 Code in the path. muse sandbox windows check still reports status=ready on this machine.
• The new message points at the permissions on the folder that holds Muse's sandbox state. I haven't changed any ACLs, so I can't say what on this machine triggers it.

@busFred thank you, that run answers the open question. Plain muse exec with the same :auto-review profile, with no T3 Code in the path, gets the same refusal from Muse's powershell tool before the command starts. So the Windows shell failure comes from Muse's Windows sandbox on that machine, not from T3 Code or this PR, and the ACL wording you found is the most specific lead so far.

I've added your result to the Windows paragraph of the PR description, so the maintainers you asked for review can see the refusal reproduces outside T3 Code.

Adding to this, hope this gets released soon :)