[only21mil]

Problem

Muse Code threads can't use Auto. Muse offers only Supervised and Full access, and musePermissionProfile sends :ask-me for every mode except Full access. A thread set to Auto, or a Muse delegate that inherits Auto from its parent, therefore runs as Supervised, where T3 asks for each approval Muse does not match, so an unwatched child waits for someone to open it.

Permission modes says Auto "uses the provider's automatic review to approve routine actions and ask about others". Muse has that review built in: its :auto-review profile ("Same access as Ask me; AI reviews eligible actions").

Closes #20739

Change

• sdk.ts: musePermissionProfile("auto") returns :auto-review. Supervised keeps :ask-me and Full access keeps :unrestricted. museApprovalMode is unchanged, so Auto keeps promptUnmatched.
• status.ts: Muse lists auto in supportedRuntimeModes, so the composer offers it and an inherited Auto no longer steps down to Supervised (fix(server): delegated Muse tasks no longer ask approval for every command #18065).
• Docs: permission-modes.md and providers-muse.md list Auto for Muse. Muse still has no Auto-accept edits.

Start and resume already pass the profile through musePermissionProfile, so the adapter needs no change.

Scope and approval

Bug report: #20739 (not triaged yet). The fix is the reporter's suggestion. It makes Muse do what the permission-modes guide already says Auto does. It follows #19712, which restored Cursor's Auto-review for Auto. The maintainer note on #19711 said "Auto is supposed to turn on Cursor's Auto-review. That was deliberate."

#19558 chose :ask-me so that Supervised leaves approvals to the user. This PR leaves Supervised alone and uses :auto-review only when the user picks Auto.

Verification

Linux (Fedora 44), in packages/provider-muse:

• Added an auto row to "selects the runtime mode's permission profile on native start and resume" in adapter.test.ts. It checks the profile and approval mode on session/start and session/resume. With main's production code the row fails (expected ':ask-me' to equal ':auto-review'). On this branch it passes, and so do all 73 tests in the package.
• tsc-rs --noEmit, vp lint and vp fmt --check on the changed files: clean.

Real app: production builds of main and this branch (vp build for apps/web, vp pack for apps/server), each with fresh state, in Chrome 156 on Linux. A Muse instance ran the real Muse Code 1.4.11 binary in an isolated home with no login, with one custom model and new threads defaulting to Auto.

On main, the new Muse thread shows Supervised and the menu has no Auto.

On this branch, the same draft shows Auto, and the menu offers it.

I sent one message on each build. T3's state stored the thread as auto both times. On main, Muse's own session log shows it committed :ask-me for the thread's session. On this branch, T3 asked for :auto-review. Muse refused it at session/start because its automated reviewer isn't available without a login.

Not checked:

• A signed-in Muse session in Auto, including what the reviewer approves and what it sends to the user. I had no Muse login in the isolated home. fix(muse): Supervised threads ask before commands again #19558 read back a signed-in 1.4.7 session under T3's handshake running :auto-review with reviewer autoReview, which is the profile this PR selects.
• Logged out, an Auto thread now fails at session/start with "the automated reviewer is unavailable on this host". On main it starts as Supervised and fails on the first turn with "not logged in". Muse turns need a login either way. I didn't check Muse setups that run turns without a Meta login (an API key or another model provider). If they have no reviewer, Auto fails to start there, and Supervised and Full access still work.
• macOS and Windows. The change is server-side policy plus the shared mode list.

Prior PRs: none for Muse Auto. #19558 (@maria-rcks) added the start and resume profiles this builds on. #18065 (@t3dotgg) made inherited modes step down per provider. #19712 (@owenferg) is the Cursor precedent. @themonkeysagents reported #20739 and proposed this mapping.

Generated with Claude Opus 5.5 in T3 Code Nightly

[macroscopeapp]

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.}

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

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

Commits

Reviewing files that changed from the base of the PR and between 2078a7a and 54a0ef2.

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.

Walkthrough

Muse now supports Auto mode through its :auto-review permission profile. The runtime declaration, permission mapping, adapter test, and user documentation reflect this support. Auto-accept edits remains unavailable.

Changes: Muse Auto mode

Layer / File(s)	Summary
Runtime mapping and mode documentation packages/provider-muse/src/server/status.ts, packages/provider-muse/src/server/sdk.ts, packages/provider-muse/src/server/adapter.test.ts, docs/user/providers-muse.md, docs/user/permission-modes.md	Muse lists auto as a supported runtime mode and maps it to :auto-review. The adapter test expects promptUnmatched approval mode. The documentation describes Auto and notes that Auto-accept edits is unavailable.

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

Change: Bug fix · Severity of issue fixed: Medium

Suggested labels: bugfix

Suggested reviewers: maria-rcks, t3dotgg

Merge Risk: Minimal · up to 54a0e

Auto mode for Muse now uses Muse's own auto-review, as the linked issue requested. Logged-out hosts already cannot send messages, so no new break is established for supported sessions. Signed-in and API-key behavior were not exercised, so spot-check both before relying on Auto.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title "feat(provider-muse): Auto mode uses Muse's own auto-review" states the main change: Muse's Auto mode now maps to the :auto-review permission profile instead of :ask-me. It follows a con…
Description check		The description follows the template's sections. Problem explains that Muse threads cannot use Auto and that the current mapping sends :ask-me. Change lists the edits in sdk.ts, status.ts and the do…
Linked Issues check		Issue #20739 requires Muse Auto for direct threads and inherited delegates, with Muse's :auto-review profile. status.ts adds auto to Muse's supported runtime modes. sdk.ts maps auto to `:aut…
Out of Scope Changes check		The whole-pull-request diff changes only Muse permission mapping, supported runtime modes, related documentation, and the regression test. Each change supports issue #20739. No unrelated behavior or f…

Full details: Title check

Explanation

The title "feat(provider-muse): Auto mode uses Muse's own auto-review" states the main change: Muse's Auto mode now maps to the :auto-review permission profile instead of :ask-me. It follows a conventional commit format and names the affected provider. The changeset matches it: sdk.ts maps "auto" to ":auto-review", status.ts adds "auto" to supported runtime modes, and the docs and tests were updated to match.

Full details: Description check

Explanation

The description follows the template's sections. Problem explains that Muse threads cannot use Auto and that the current mapping sends :ask-me. Change lists the edits in sdk.ts, status.ts and the docs. Scope and approval links the bug report #20739, which is not yet triaged, and explains why the change fits the permission-modes guide and the Cursor precedent (#19712). Verification gives focused test results, type and lint checks, and before/after screenshots and readback. It also lists what was not checked. The template asks for maintainer approval of scope. The author links an untriaged issue and argues it qualifies as an obvious fix of a focused configuration. That argument is reasonable, but the maintainer approval is not yet shown. The template also asks for the model and harness used, and the author gave 'Claude Opus 5.5 in T3 Code Nightly'. Overall the description is mostly complete, so it passes.

Full details: Linked Issues check

Explanation

Issue #20739 requires Muse Auto for direct threads and inherited delegates, with Muse's :auto-review profile. status.ts adds auto to Muse's supported runtime modes. sdk.ts maps auto to :auto-review, keeps Supervised as :ask-me, and keeps Full access as :unrestricted. Existing native start and resume paths use this mapping. The regression test checks the Auto profile and promptUnmatched approval mode for start and resume. The documentation records the supported modes and the absence of Auto-accept edits.

Full details: Out of Scope Changes check

Explanation

The whole-pull-request diff changes only Muse permission mapping, supported runtime modes, related documentation, and the regression test. Each change supports issue #20739. No unrelated behavior or files appear in the diff.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

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

Usage-based review receipt

• Mode: Continue automatically
• Reviewed files: 4
• Charged: $1.00
• View usage details

Note

This review was completed with usage-based billing: files reviewed beyond your plan's included limits are billed at $0.25/file. View usage-based billing.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

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.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

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.

main: t3 thread start --base-dir .t3 --provider muse --model muse-spark-1.3
      --wait --json /home/user/verification-repo "Run pwd. Do not change files."
=> status: failed; not logged in: run /login to add an API key

pr: web client selects Auto and submits the same prompt
=> Muse session/start rejected permission profile :auto-review:
   the automated reviewer is unavailable on this host

t3 thread show --base-dir .t3 --json <muse-thread>
=> providerInstanceId: muse; model: muse-spark-1.3; runtimeMode: auto; status: failed

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.

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.