Muse Code is Meta’s terminal coding agent. It installs as a muse binary and runs as a full-screen TUI inside your repository, the same shape as Claude Code, Codex or opencode. Termic ships it as a built-in agent, so there is nothing to configure: install muse, open a task, and it launches in its own git worktree with resume, sandboxing and work-done notifications already wired.
Every flag on this page was measured against a live Muse Code 1.0.2 rather than read off its help text, which is the same standard the other built-in agents are held to.
Getting started
- Install Muse Code from Meta’s instructions. The launcher drops a
museshim into~/.local/bin, which re-execs a versioned binary beside it and self-updates. - Open Termic. Any
museon yourPATHis detected automatically and shows green in the new-task picker and the new-tab menu. - Create a task with muse selected. Termic makes a git worktree off your base branch and starts
musein it.
There is no API key to paste into Termic and no config file to edit. Termic spawns the real CLI, so your existing muse login session, your ~/.config/muse settings and your workspace AGENTS.md all apply unchanged.
One worktree per task, so instances never collide
Each Termic task is a git worktree, which is what makes running several Muse Code sessions at once safe: two tasks are two directories, two branches and two muse processes that cannot see each other’s uncommitted work. You can put three Muse Code tasks on three different bugs, or run Muse Code, Claude Code and Codex against the same ticket at once and keep the diff you like (see parallel agents and agent races).
Session resume
Close the window, restart the app, come back tomorrow: reopening a task reconnects Muse Code to the conversation it was having, rather than starting a blank one.
- In a worktree task, Termic relaunches with
muse resume --last. Sessions are scoped to the workspace directory and each task has its own, so “the last session here” is unambiguously this task’s. - In a repo-root task, several tasks share one directory, so
--lastwould be whoever ran most recently. Muse Code will not accept a session id at launch (--session-idis anexec-only flag and its TUI rejects it), so Termic captures the id after the run instead and relaunches withmuse resume <session-uuid>. - In a Docker task, that capture reads the container’s own session directory, not your host one, so the id it replays is one the container has actually seen.
If there is no prior session, muse resume --last exits cleanly and Termic relaunches fresh, so a first run is never blocked by a failed resume.
Approvals, YOLO and the sandbox
Muse Code arrives with its own tool-approval prompt and its own macOS seatbelt sandbox, both on by default. Termic leaves both alone for an uncaged task.
When you sandbox a task, Termic passes --yolo, which turns Muse Code’s own approval prompt and its own cage off for that run. That is deliberate: Termic’s cage becomes the single boundary instead of nesting two seatbelt profiles inside each other, and it is the same rule every other agent follows (a caged task is where an agent is allowed to work unattended, because the cage is the real limit).
What a caged Muse Code task gets:
- Filesystem: the worktree, plus Muse Code’s own state. That means
~/.config/muse,~/.local/share/muse(where session logs and skills live),~/Library/Application Support/Muse(which it reads and writes on every launch), and only its own files inside~/.local/bin, never the whole directory that other agents’ binaries also sit in. - Network: Muse Code’s vendor hosts are on the allowlist by default, so login, the Model API and the launcher’s self-update all work inside the cage. Everything else is refused until you allow it, per task or per agent.
- Docker: Muse Code is one of the agents whose state directories Termic mounts and persists in the Docker sandbox, so your login and your sessions survive the container being rebuilt.
The workspace trust prompt
Muse Code asks “Do you trust this workspace?” and keys the answer to the directory, not the repository, so every new worktree asks again. Termic answers it for you only when it is starting a task and sending the first prompt itself (an agent race, a run from the prompt library, a launch from the CLI), by passing --trust-workspace, which trusts for that run only. When you launch a task and type into it yourself you get the picker and answer it yourself.
This matters more than it sounds: in that picker n selects Quit and a space confirms it, so a prompt injected before the picker is answered can exit the agent partway through being typed.
Work-done detection and notifications
Muse Code is unusually well behaved here. Its terminal title carries real state: a braille spinner while the model is running, the bare workspace name when it is idle. Termic reads that directly, so the spinner in the sidebar, the done dot and the notification when a turn finishes all work with no configuration.
It also never puts its final message on OSC 9, so a finished turn does not masquerade as “the agent needs you” the way it can for agents that do.
Termic does not need to install anything into Muse Code to get this. Some agents report their state through a hooks integration Termic can set up for them; Muse Code does not need one, and could not use it anyway, because it strips the environment it hands a hook command. Its title is enough on its own.
Testing without spending tokens
Muse Code ships an offline provider: muse --provider echo runs the full TUI, hooks and all, against a canned responder. If you want to see how Termic drives it (worktrees, resume, the sandbox, the work-done dot) without touching your quota, set --provider echo in the agent’s default args in Settings → Agents, try it, then take it back out.
Related
- Agents & the registry: every built-in, and how to add your own CLI.
- Parallel agents: running Muse Code alongside Claude Code and Codex.
- Sandbox overview: what a caged task can and cannot do.
- Work-done & notifications: how Termic knows a turn ended.