-
Notifications
You must be signed in to change notification settings - Fork 3
plat 468
PLAT-468 — Muse chats on a Mac start with no MCP bridge (Seatbelt refused Muse's read of the folders above its working folder)
| Coordination | Value |
|---|---|
| State | fixed on main (provider 4dba54e, pinned e6cc149); needs a rebuild and backend restart |
| Date | 2026-10-04 |
| Owner | coding-agent-bridge |
| Related | PLAT-394 (Mac Seatbelt for all CLIs), PLAT-463 |
The owner's Muse Builder chats for jobsearch and upwork could not call any platform
tool (get_contract_upgrades, set_workflow_contract_version, decisions). The server
built the bridge config (6 tools) and wrote mcpServers.api-bridge into Muse's
settings, but no mcpbridge process ever started. Muse printed MCP configuration error in <runtime>/.mcp.json; MCP is disabled for this runtime. The jobsearch agent
then hand-edited workflow.json to stamp contract 1.0.45.
Muse's own bootstrap log (~/.local/share/muse/sessions/<date>/<id>/cli-*.log)
says mcp.config.resolve stage="startup" outcome="failed" reason="source_reservation" server_count=0. Muse walks up from its working folder looking for project sources
and must read every folder on the way. Under the Mac Seatbelt the runtime folder lives
inside the closed AgentWorks state area, whose parent folders were allowed
metadata-only, so the read was refused, MCP startup failed and the chat had no
bridge. It was reproduced outside the app by running the Muse TUI under the same kind
of profile (fails), then adding a literal file-read-data grant on the four folders
above the runtime folder (works; any three of the four still fail). Project rules
(AGENTS.md), the path's space, the environment and an empty .mcp.json were each ruled
out by experiment. Codex and Claude do not walk up this way and were unaffected.
-
multi-llm-provider-go
internal/clisandbox/seatbelt.go: formuse-clithe ancestor folders get(allow file-read-data (literal ...))next to the metadata grant. Names of siblings become listable; nothing inside the closed folders opens. Other CLIs' profile is unchanged. -
seatbelt_darwin_test.go: under the real sandbox, Muse can list the three folders above its runtime folder, Codex cannot, and Muse still cannot list or read another runtime. -
agent_go/go.modpins multi-llm-provider-go ate6cc149(includes4dba54e). The first push of the provider fix did not bump this pin, so the server built after the owner's 19:57 restart still had the old sandbox and the relaunched Muse chats (muse resume) failed the same way. A provider change reaches the app only through this pin.
- Takes effect on the next backend restart (the running server holds the old code).
- Chats started before the restart stay without a bridge; start a new chat or switch provider and back.
- Workflows migrated by hand-editing
workflow.jsonwhile the bridge was missing (jobsearch) should be re-checked withget_contract_upgradesonce a chat has the bridge. A Muse run with project rules and the real bridge was not re-run end to end after the fix; the reproduction used the same profile shape.
Auto-synced from docs/ on main. Edit there, not here.