[teamleaderleo]

acpmux: approval paths for no-ask start modes that don't need the person each time, plus pending prompts that reach peered apps.

When a script or agent asked acpmux for a mode that doesn't ask, the request needed the person's approval. That approval was only visible in cmux NEXT on the same host, and the error didn't say where to give it. The threat model is written at the top of hub/person.rs.

• (a) Inherit. A session can start new sessions in its own current no-ask mode, on the same harness family.
  • The daemon proves which session is calling. Each harness it starts gets ACPMUX_SESSION_TOKEN, an HMAC of the session id keyed by a secret made at each daemon start and kept only in memory.
  • The token is checked on the connection's first initialize, and only over the unix socket.
  • The caller's mode is read at request time, so a session the person moved back to asking inherits nothing.
  • Peer and Web connections never have a caller.
• (b) Person-approved preset. _acpmux/presets {name, approveMode: true} from the person records a sha256 of the preset's contents.
  • The approval holds only while the preset still hashes to it, and only for that preset's own mode.
  • Any edit to the preset drops it.
  • Without the person, approving a preset's no-ask mode is refused.
• (c) Pending prompts across peers. A peer's _acpmux/permission_pending reaches this daemon's watchers that did not attach the session (via: "peer").
  • Answers still go to the peer, which counts an allow only with its own person's proof.
• (d) Refusal text. The error names where to approve: cmux NEXT on this host, or the preset to approve there once.
  • error.data carries {reason, host, mode, preset} so an app can show localized text.
• Fits with the base start mode (cx-wx93i).
  • A request that names a mode skips the default start mode, and (a) and (b) gate it.
  • A proven caller session that asks never gets the full-access default for its chats: they start in the harness's own mode.

Review fixes

From the security review:

1. Adopt plus a start mode. A start mode that does not ask, on a session/new that adopts, now needs the person. The request is refused before anything starts, because an adopt may find a session that is already running (ifLive: "open"), and only the person widens a running session.
2. Peer-relayed pending prompts. A peer's _acpmux/permission_pending is relayed only when all of these hold:
   • the session is one that peer listed as its own, and it is not a session of this daemon;
   • the prompt is in the daemon run the peer named at its handshake;
   • that run is neither this daemon's nor one another peer named.
     It goes only to unix-socket and app watchers, never to a Web client and never on to another peer daemon.
   • Content binding (decision): not done. The decision proof covers the prompt's ids, not its text, and binding it to the text needs the app to hash what it shows. The checks above keep this daemon's own prompts, which the app on this host can prove, from arriving with a peer's text. The residual case is in the threat model.
3. Preset approval only gated the start. One session/new reads the preset's contents at three points: the request check; the resolve of model, effort and env; and the spawn of args, env and system prompt.
   • The resolve and the spawn each record the digest of what they used.
   • The start counts the approval only if both digests equal the approved one. An edit that is put back between reads gains nothing.
   • A preset with a mode or an approval never takes a pooled harness.
   • The session records the approved digest. A respawn from other contents starts in the harness's own mode instead of replaying the approved one.
4. Harness name. Documented: the approval covers the preset's harness string, not the profile that name resolves to.
5. Overrides (decision): a request that adds its own model, effort, policy or env to an approved preset needs the person. A folder (cwd) is fine.
6. modeApproval. Documented: it is an unkeyed sha256, so same-uid writes to config.json are out of scope.
7. Host name. A Web or peer client never gets this host's name, in the refusal text or in error.data.host.
8. Caller token. The daemon also sets ACPMUX_SESSION_TOKEN_SOCKET. The CLI sends the caller token only when it connects to that socket.

Out of scope, and pre-existing on the base: a peer can send session/update for a local session id. Tracked as bead cx-r492l.

Second review

1. A request during the start rebound the approval. The spawn digest was written before spawn_lock, so a request on the session while an approved preset was starting could overwrite it. ensure_child now records the digest it spawned with, under spawn_lock, and only when it starts a new harness. A live or re-adopted child never writes it.
2. The saved mode was cleared while the harness kept its no-ask mode. The saved mode is now dropped only when a new harness actually starts from other contents. For a live or re-adopted child, the saved mode still says what the harness runs.
3. A peer can name a third daemon's run. Documented as a residual in person.rs and below in open questions. Tracked as bead cx-i4rte.
4. ACPMUX_SOCKET is made absolute, so a relative path cannot point the CLI and the daemon at different sockets.
5. Forgetting a mode now clears every mode field (MODE_FIELDS), not only modeId.

Open questions for review

• Unproven unix-socket clients. With the base default start mode, any unix-socket client that is not a proven session gets a full-access chat without the person. That includes an agent in an asking mode that just leaves its token out. Applying the default only to the person or app connections would close that, but it changes base behavior, so it is Lawrence's call. Not changed here.
• Readable token. A caller token can be read by any process of the same user (/proc/<pid>/environ, ps -E). It grants only that session's current mode, which its own agent can already use. Binding the token to the connecting process's ancestry is later hardening.
• No cross-peer inherit.
• Binding a decision proof to the prompt text would need the app to hash the text it shows (see Review fixes, 2).
• A peer naming a third daemon's run. A peer can name, as its own run, the personInstance of another daemon the app enrolled directly. The app must refuse to prove a via: "peer" prompt whose personInstance is a daemon it enrolled directly. This needs an app change (bead cx-i4rte).
• Restoring a preset restores its approval. Reverting a preset to the exact contents the person approved makes the approval valid again.

Not in this PR

• The cmux NEXT notification for a peer-forwarded pending prompt.
• Live verification that a pending prompt shows in the pane on another Mac.

Tests

The tests are at the daemon boundary: tests/person_auto_start.rs (auto_start_*) and a peer test in tests/peer_integration.rs for the pending prompt (c).

• Red on 4814e6a (auto_start_): left: "full-access", right: "normal". A chat started by an agent in an asking mode came up in full access.
• Hosted Linux green on f04c419 for auto_start_, peer, start_mode and preset.
• Review fixes, boundary tests committed red first (d3ba5e7):
  • auto_start_, red on Linux: 3 failed, 9 passed. An adopt moved a running session to bypass, a request model override started without the person, and a respawned edited preset came back in bypass.
  • peer_pending, red on Linux: 3 failed, 1 passed (the legit relay). A forged prompt (local session, this daemon's run, unknown session) reached the watcher.
• Green on Linux at 0f34db0:
  • auto_start_: 12 passed (run 38592681245).
  • peer: 75 passed (run 38600221583).
  • preset: 26 passed (run 38601708940).
• Second review, boundary test committed red first (14f2ddb): auto_start_a_request_during_the_start_never_rebinds_the_approval, red on Linux (run 38611185844). The start was refused with permission.person_required.
• Green on Linux at 68914f2:
  • auto_start_: 13 passed (run 38618842274).
  • peer: 75 passed (run 38626137238).
  • preset: 26 passed (run 38635193026).
• In the 68914f2 runs, macOS failed on a base clippy lint in cmux-tui/tests/replace_unresponsive_owner.rs (unused qualification), which this PR does not touch.
• After merging base (915952c, which picks up the base clippy fix from cmux-tui: clear the base clippy red in replace_unresponsive_owner #20654), hosted green on Linux and macOS:
  • auto_start_: Linux 19 passed, macOS 44 passed (run 38640660645).
  • peer: Linux 77 passed, macOS 101 passed (run 38643120684).
  • preset: Linux 26 passed (Linux job rerun after a cancel), macOS 51 passed (run 38646576474).
• macOS was queued because the pool is starved, so these runs were cancelled after their Linux test job.

Changelog

• Changed: acpmux sessions can start sessions in their own no-ask mode, the person can approve a preset's mode once, and a pending approval reaches peered apps. The refusal names where to approve.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Adds approval paths for starting acpmux sessions in a no-ask mode without the person, relays pending approval prompts to peered apps, and keeps the motion system and Chief work the base merge brought in.

• Inherit. A proven caller session (an HMAC token the daemon places in its env, checked at the connection's first initialize) can start sessions in its own current no-ask mode on the same harness family; claims in request params are ignored. The CLI sends its caller token only to the socket of the issuing daemon (ACPMUX_SESSION_TOKEN_SOCKET), and ACPMUX_SOCKET is made absolute.
• Approved preset. The person can approve a preset's no-ask mode once; the approval binds to the preset's contents via sha256, so any edit drops it. A request that adds its own model, effort, policy or env to an approved preset still needs the person.
• Pending prompts across peers. A peer's pending prompt reaches this daemon's watchers that didn't attach the session; answers still go to the peer and need its own person's proof.
• Refusals. Name where to approve — the host's cmux NEXT or a preset — with host, mode and preset in error.data.

Security boundaries

• A no-ask mode never applies to an adopt, and approved-preset starts never take pooled harnesses; the approval counts only when both the resolved and spawned contents hash to the approved digest, recorded only on a cold start under the spawn lock so a racing request can't rebind it.
• The default full-access start mode never widens a caller session that asks.
• A peer's pending prompt is relayed only for a session the peer listed as its own, in the run the peer named at its handshake, to unix-socket and app watchers only.

Rode in from the base merge

• Chrome motion (hq-1d): closed-form springs on one MotionClock per window, ui.animations.newTab (on by default) and ui.animations.newWorkspace, bounce and Reduce Motion switches; a new tab grows in at its slot on the tabOpen spring, structural changes snap under Reduce Motion. Palette rows for "Window Style" preview the style live while highlighted.
• Chief: chief.profile.adopt makes an existing agent participant a Chief record under its own id (refuses a bound participant, revokes its earlier credentials); a brain started by the supervisor gets the account's home; every Chief profile page call answers within a deadline on a relay connection to the current owner. labs.classicHome keeps classic Home one release; the agent CLI card's harness.update/harness.restart run on this Mac's daemon with a gesture.

^{Written for commit 7f2b6a3. Summary will update on new commits.}

[github-actions]

Not verified: macOS jobs did not run: compile and app tests were skipped on 7f2b6a385c; ci-status is green without them.

CI passes on 7f2b6a385c (run 38689792764 attempt 1).
macOS jobs did not run: compile and app tests were skipped: Fast static checks skipped (the macos job needs both to succeed). Re-run CI once they pass, before merging.

Written by scripts/ci/classify_failures.py (ci-failure-attribution.yml); signatures are its SIGNATURES table. A machine verdict is the runner's fault, not this PR's; yours means the failing file is one this PR changes, also red on main that main's latest full suite fails the same way, seen on other PRs that it failed on another pull request's run lately.

[teamleaderleo]

Split plan

This PR isn't a mega-PR. The 803-file count is measured against main, but the PR targets feat-cmux-next, and acpmux doesn't exist on main at all. Measured against its merge base with feat-cmux-next (0664bd9847b5), the PR is 14 commits, 31 files, +1933/-86, all in cmux-tui/crates/acpmux/ plus the two generated plans/cmux-next/ action files. It doesn't touch web/ or workers/, so the BSL CLA rule doesn't apply.

Bucket	Files	Lines
Feature code (start gate, caller token, preset approval, peer prompts, refusal text)	25	~960
Tests (person_auto_start.rs, peer_integration.rs, hub_integration.rs, fake_agent.py)	4	~910
Generated (plans/cmux-next/action-surfaces.json, actions.md, regenerated by PR autofix)	2	~67

None of it is on feat-cmux-next yet: hub/start_gate.rs and tests/person_auto_start.rs don't exist there. A merge into current feat-cmux-next conflicts in 5 files, and each conflict is small:

• server/mod.rs: one use line (SessionReceipt, EventRecord).
• server/requests.rs: keep_harness_mode next to the new route field. Keep both.
• tests/fake_agent.py: FAKE_PLAN_MODE next to FAKE_FULL_ACCESS. Keep both.
• The two plans/cmux-next files: regenerate them.

Recommendation: don't close it. Resolve those 5 conflicts and land it into feat-cmux-next as one PR. The two security reviews were done on the combined head, and the security checks in (a), (b) and (c) share hub/person.rs and server/mod.rs. If a reviewer wants it smaller, here's how it splits, in landing order. Each slice targets feat-cmux-next and regenerates the plans files:

1. Peer pending prompts (c), 7 files. peer.rs (personInstance from the handshake), hub/peers.rs (peer_pending_counts and the relay), hub/mod.rs (export), server/pending.rs (moved out of server/mod.rs), the deliver hunk in server/mod.rs, the (c) section of hub/person.rs, and tests/peer_integration.rs.
2. Inherit plus refusal text (a)(d), about 15 files. hub/start_gate.rs without the preset parts, ACPMUX_SESSION_TOKEN and _SOCKET in hub/spawn.rs, client.rs, cli/command.rs, cli/run/standard.rs, agent/command.rs, the caller hunk in server/mod.rs, server/requests.rs, hub/session.rs, hub/lifecycle.rs, hub/fork.rs, docs/acpmux-schema.json, the (a)(d) sections of hub/person.rs, fake_agent.py, hub_integration.rs, and the inherit and refusal tests from person_auto_start.rs.
3. Person-approved preset (b), about 10 files. hub/start_gate/preset_bind.rs, server/requests/presets.rs, config.rs, config/preset_args.rs, cli/orchestrate/presets.rs, hub/pool/mod.rs, hub/resolve.rs, store.rs, the digest part of hub/spawn.rs, the (b) section of hub/person.rs, and the preset tests from person_auto_start.rs.

Shared files: #20549 also edits config.rs, hub/lifecycle.rs, hub/mod.rs, hub/person.rs, hub/resolve.rs, server/requests.rs, fake_agent.py and hub_integration.rs. #20963 also edits hub_integration.rs and peer_integration.rs. #20706 also edits the two plans files. The hunks listed above are this PR's own, and the other PRs' changes in those files are owned by their splits. server/mod.rs and server/requests.rs land with #21322 (composer-stack), so no slice is carved here until that's settled.

Slices opened

1. acpmux: a peer's pending prompts reach this daemon's watchers #21642: a peer's pending prompts reach this daemon's watchers. Merged (2cf3534).
2. acpmux: no-ask start modes by inherit or an approved preset #21666: no-ask start modes by inherit or an approved preset. Review fixes are in, and it's rebased onto feat-cmux-next now that acpmux: a peer's pending prompts reach this daemon's watchers #21642 has merged.

Follow-up slice (not coded yet)

• server/pending.rs peer_permission_pending: send the session's qualified_id, not the bare mux id, so the relayed notification names the same session as the peer's other records since feat(next): carry explicit session lifecycle receipts #21397.
• Tests in peer_integration.rs for:
  • a prompt whose personInstance doesn't match the run the peer named at its handshake (dropped);
  • two peers that name the same run (dropped for both);
  • a Web watcher (never gets a peer's prompt).

Separate from this PR (needs its own bead): since #21397, a peer picks its own host_id, so it can overwrite another peer's qualified key in remote_sessions (hub/peers.rs, the map.insert(id, ...) around line 350).

🤖 Generated with Claude Code

[teamleaderleo]

Slices opened, both targeting feat-cmux-next:

1. acpmux: a peer's pending prompts reach this daemon's watchers #21642: a peer's pending prompts reach this daemon's watchers (7 files). One change from this PR: the session lookup goes through SessionReceipt.
2. acpmux: no-ask start modes by inherit or an approved preset #21666: no-ask start modes by inherit or an approved preset (the remaining 25 files, stacked on acpmux: a peer's pending prompts reach this daemon's watchers #21642). It also makes person_auto_start.rs hermetic and its person-key pipe close-on-exec.

Together they cover all of this PR's own change. The plans/cmux-next diff here was regenerated base drift, so it isn't carried. Once both merge, this PR can be closed.

🤖 Generated with Claude Code

[teamleaderleo]

Already landed: the no-ask start modes as #21666 and the peer pending-prompt relay as #21642. Closing.