@vibelord/lanes 1.5.0 → 1.6.0

package/payload/lanes/docs/INSTALL.md

@@ -118,14 +118,15 @@ account with UID 1000. With `--write` it then applies these steps in order:
    or to the title the board already has. A board that already disagrees stops the run before the container is
    touched.
 2. **Contract.** Runs `lanes install-container`: the `lane` contract, and the Lanes MCP server (`lane-mcp`) in
-   Claude Code's `~/.claude.json` and Codex's `~/.codex/config.toml`, and in Kimi Code's, Grok Build's and grok-cli's
-   files where those harnesses are installed (only where it is missing; the old file is kept
+   Claude Code's `~/.claude.json` and Codex's `~/.codex/config.toml`, and in Kimi Code's, Grok Build's, grok-cli's,
+   Muse Code's and ZCode's files where those harnesses are installed (only where it is missing; the old file is kept
    as `<file>.bak-<UTC time>`). The `lane-mcp` row of the table then says whether that changed either file.
 3. **Agent hooks.** Runs `lanes hooks install --write`, first for Claude and then for Codex. Your own hooks and
    keys are kept, with a backup of each changed file. A Lanes hook group that is already installed stays where
-   it is, even when Throttle's setup has added its own group around it. Then for Kimi Code, Grok Build and grok-cli
-   (`hooks-kimi`, `hooks-grok`, `hooks-grok-cli`), each only when its home (`~/.kimi-code`, `~/.grok-build`, `~/.grok`)
-   is in the container, else `skipped`. Two steps run only when you name them: `--step kimi-notify` (Kimi Code's
+   it is, even when Throttle's setup has added its own group around it. Then for Kimi Code, Grok Build, grok-cli, Muse Code
+   and ZCode (`hooks-kimi`, `hooks-grok`, `hooks-grok-cli`, `hooks-muse`, `hooks-zcode`), each only when its home
+   (`~/.kimi-code`, `~/.grok-build`, `~/.grok`, `~/.config/muse`, `~/.zcode`) is in the container, else `skipped`
+   (Lanes installs neither Muse Code nor ZCode). Two steps run only when you name them: `--step kimi-notify` (Kimi Code's
    `tui.toml` `notification_condition = "always"`) and `--step grok-build` (Grok Build installed into
    `~/.grok-build` from its stable channel, before step 2, so its MCP entry and hooks land in the same run; the
    channel publishes no checksum, so the receipt's `warn` row records the download's size and sha256 as
@@ -263,7 +264,10 @@ cd bw-tools/lanes
 ```
 
 OpenSSH is required. Install Ghostty for a dedicated window, or run `lanes-launch` in your existing terminal.
-Linux also supports Foot, plus optional Omarchy/Hyprland shortcuts. Tailscale is required when your profile uses
+Linux also supports Foot, plus optional Omarchy/Hyprland shortcuts. The dedicated Ghostty window defaults to
+Catppuccin Latte in light mode and Dracula in dark mode. On Omarchy, its launcher preserves everyday fonts, padding
+and shortcuts while excluding inherited theme colors so this pair takes effect; the everyday Ghostty config is left
+untouched. Tailscale is required when your profile uses
 a tailnet address. When the profile's `LANES_SERVER_NAME` ends in `.ts.net`, the installer checks Tailscale before
 the server: without it, it prints `tailscale: not installed — macOS: brew install --cask tailscale · Linux:
 https://tailscale.com/download` and exits 4 (the client is installed); on a logged-out machine it prints

package/payload/lanes/docs/RUNBOOK.md

@@ -378,7 +378,16 @@ lanes studio-host re-key --yes       after the owner revoked the Host: a new mac
   stderr. Writes are atomic and only on a change; the file stays 0600 and `~/.ssh` 0700. A non-default sshd
   `AuthorizedKeysFile` does not read this block.
 
-- **A view looks wrong / stuck:** `lanes rebuild mac`. Views are disposable; agents are untouched; the client reconnects.
+- **A desktop stops accepting keys while SSH stays connected:** reconnect that window's display first (close and
+  reopen the Lanes window, or terminate only its verified SSH display child so `lanes-launch` retries). Do not
+  restart holders or containers. `lanes attach` now supervises its Zellij client with `libexec/attach.py`: output
+  waiting to reach the terminal is limited to 1 MiB and an oldest pending chunk age of 5 s. Either bound ends only
+  that client (TERM, then KILL after 1 s if needed), exits 1, and lets `lanes-launch` reconnect to the existing view.
+  Idle terminals have no deadline; input, resizing and normal exit codes pass through. A client that cannot drain
+  its terminal cannot be rescued by SSH keepalives alone (DEF-1965). This guard covers desktop SSH attachments;
+  Zellij's browser transport does not use it. Already attached desktops pick it up on their next attachment.
+- **A view's layout looks wrong:** `lanes rebuild mac`. Views are disposable; agents are untouched; the client
+  reconnects. Rebuilding also ends that view's Host tab shell, so prefer a display reconnect for a frozen client.
 - **A lane was added/renamed/removed in a repo's `.vscode/terminals.json`:** nothing to do. `lanes-sync.timer`
   re-reads registries every 2 minutes and the sidebar follows. The zellij layout is never edited live. A sync that
   finds nothing new leaves `registry.json` (and its `generated_at`) untouched and only records the time in
@@ -997,8 +1006,9 @@ whose agent is alive but silent keeps the last word for up to an hour.
 ## Harnesses
 
 Since 1.5.0 (W12, spec `docs/superpowers/specs/2026-10-15-lanes-harness-observers-design.md`) Lanes reads Kimi Code,
-Grok Build and grok-cli lanes as well as Claude Code and Codex ones; what each status means for the person at the
-board is the user guide's [Harnesses](USERGUIDE.md#harnesses). This section is the operator's: what to install per
+Grok Build and grok-cli lanes as well as Claude Code and Codex ones, and since 1.6.0 (W13, spec
+`docs/superpowers/specs/2026-10-16-lanes-harness-observers-muse-zcode-design.md`) Muse Code and ZCode lanes; what each
+status means for the person at the board is the user guide's [Harnesses](USERGUIDE.md#harnesses). This section is the operator's: what to install per
 container, how statusd decides, and how to check each harness. Claude Code's and Codex's hooks are in "Installing
 agent hooks" above.
 
@@ -1010,19 +1020,22 @@ changes, a symbolic link below the container home refuses the file, and in a TOM
 
 1. `lanes install-container <name>` — ships 1.5.0's contract: `lane-signal` (its harness, when no `--harness` or
    `LANE_HARNESS` names one, read from the parent processes, never assumed `codex`), `lane-mcp` and its editors, and
-   the hook definitions in `~/.lz/hooks/` (`kimi-hooks.toml`, `grok-hooks.json`, `grok-cli-hooks.json`). Unless
+   the hook definitions in `~/.lz/hooks/` (`kimi-hooks.toml`, `grok-hooks.json`, `grok-cli-hooks.json`, and since 1.6.0
+   `muse-hooks.json`, `zcode-hooks.json`). Unless
    `--no-mcp`, it also runs `~/.lz/bin/lane mcp install`, which adds the Lanes MCP server for each harness installed
    there, beside Claude's and Codex's entries (each subsection below names its file).
 2. The hooks of each harness the container has, each with its dry run first: `lanes hooks install --agent kimi
    --container <name>` ([Kimi Code](#kimi-code)), `--agent grok` ([Grok Build](#grok-build), after Grok Build is
-   installed) and `--agent grok-cli` ([grok-cli](#grok-cli)).
+   installed), `--agent grok-cli` ([grok-cli](#grok-cli)), `--agent muse` ([Muse Code](#muse-code)) and `--agent
+   zcode` ([ZCode](#zcode)).
 3. Optional, the operator's call per container: `lanes onboard <login> --container <name> --step kimi-notify --write`
    (Kimi Code's bell) and `--step grok-build --write` (installs Grok Build).
 4. New agent sessions read the hooks and the MCP entry; a running session keeps what it started with (inferred from
    how the harnesses read their configuration at start, not measured).
 
 `lanes onboard` runs step 2 by itself for each harness whose home is in the container (`hooks-kimi`, `hooks-grok`,
-`hooks-grok-cli`; `skipped` otherwise); `kimi-notify` and `grok-build` run only when named with `--step`
+`hooks-grok-cli`, `hooks-muse` for `~/.config/muse`, `hooks-zcode` for `~/.zcode`; `skipped` otherwise — Lanes installs
+neither Muse Code nor ZCode); `kimi-notify` and `grok-build` run only when named with `--step`
 (`grok-build` right after the board, before the contract, so the same run writes Grok Build's MCP entry and hooks).
 
 What each event writes (`agent{}` vocabulary):
@@ -1039,22 +1052,35 @@ What each event writes (`agent{}` vocabulary):
 | Grok Build | `StopFailure` / `SessionStart` / `SessionEnd` | `errored` / `idle` / `shell` |
 | grok-cli | `UserPromptSubmit`, `PreToolUse`, `PostToolUse` | `working` |
 | grok-cli | `Stop` / `StopFailure` / `SessionEnd` | `needs_input` / `errored` / `shell` |
+| Muse Code | `UserPromptSubmit`, `PreToolUse`, `PostToolUse`, `PostToolUseFailure` | `working` |
+| Muse Code | `PermissionRequest`, `Notification` | `needs_approval` |
+| Muse Code | `Stop`, `Interrupt` (async) | `needs_input` |
+| Muse Code | `StopFailure` / `SessionStart` / `SessionEnd` | `errored` / `idle` / `shell` |
+| ZCode | `UserPromptSubmit`, `PreToolUse`, `PostToolUse`, `PostToolUseFailure` | `working` (`needs_input` when the hook says `is_interrupt`) |
+| ZCode | `PermissionRequest` | `needs_approval` |
+| ZCode | `Stop` / `SessionStart` | `needs_input` / `idle` |
 
 Verified event names (2026-10-15, this host): Kimi Code 2.1.1's `HOOK_EVENT_TYPES` and its strict `[[hooks]]` schema
 (`event`, `matcher?`, `command`, `timeout?` 1–600) in its binary; grok-cli 1.1.7's hook events, its exact-string
 matcher, `sh -c` with its own environment, and its MCP server entry (`{id, label, enabled, transport, command, args,
 env}`, client name `grok-cli-<id>`) in the source its binary carries; Grok Build 1.0.52's events from its source and
 user guide (`docs/superpowers/specs/evidence/2026-10-15-grok-build-measurement.md` §3). Not yet proven on a live,
-logged-in session: that each harness fires these hooks in a lane as the source says.
+logged-in session: that each harness fires these hooks in a lane as the source says. Muse Code 1.4.10 (2026-10-16, a
+scratch HOME with the offline `--provider echo`, never a credential): its hook shape, `schema_version` 1, the
+`async` Interrupt and the cleared hook environment MEASURED; SessionStart fires right before the first prompt, not at
+launch (MEASURED); `PermissionRequest`, `Notification`, `StopFailure` and `Interrupt` firing NOT measured (the echo
+provider asks for no permission and cannot fail or be interrupted in time). ZCode's events are its README's; ZCode was
+not run (needs_operator_capture, DEF-2060).
 
 ### The observed harness
 
 Which harness runs in a lane needs nothing installed: statusd OBSERVES it instead of guessing it from the pane title.
 It walks the pane's process tree in the container's `/proc` (`/proc/<pid>/task/*/children` and the `comm` of each
 process, breadth first from the pane's root, at most four levels and 64 processes, no spawn) and publishes
-`agent.harness` as `claude`, `codex`, `kimi`, `grok` (Grok Build), `grok-cli`, `shell` or `unknown`. The first process
-whose `comm` is `claude`, `codex`, `kimi`/`kimi-code` or `grok`, or whose executable holds `/claude/versions/`, names
-it: native Claude Code before 2.1.299 runs with its version as `comm` (`2.1.295`), so its executable names it
+`agent.harness` as `claude`, `codex`, `kimi`, `grok` (Grok Build), `grok-cli`, `muse` (Muse Code), `zcode` (ZCode),
+`shell` or `unknown`. The first process whose `comm` is `claude`, `codex`, `kimi`/`kimi-code`, `grok`, `muse` (Muse's
+launcher script) or `zcode-cli` (ZCode's process title), or starts with `muse-bin-` (MEASURED: `muse-bin-1.4.10`), or
+whose executable holds `/claude/versions/` or is a file named `muse-bin-…`, names it: native Claude Code before 2.1.299 runs with its version as `comm` (`2.1.295`), so its executable names it
 (DEF-1993; the same rule as `lane-signal`'s and `lane_core`'s). A `grok` is Grok Build when its executable is
 `…/downloads/grok-linux-<arch>` (`readlink /proc/<pid>/exe`), any other is grok-cli; one whose executable cannot be read
 is `unknown`. Only shells is `shell`; anything else, a cut tree or an unreadable read is `unknown`. The answer is kept
@@ -1068,15 +1094,18 @@ found exited or now runs under another `comm`; `shell` and `unknown` are never k
 | Kimi Code | `kimi-code` (or `kimi`) | `~/.kimi-code/sessions/…/state.json` + `agents/main/wire.jsonl` | `kimi-session-file` |
 | Grok Build | `grok`, exe `$GROK_HOME/downloads/grok-linux-<arch>` | `$GROK_HOME/active_sessions.json` + the session's `events.jsonl` and `summary.json`, else its pane title | `grok-session-file`, `grok-title` |
 | grok-cli | `grok`, any other exe | nothing: no title, no bell, no pid in its database | — (hooks only) |
+| Muse Code | `muse-bin-<version>` (exe `~/.local/bin/muse-bin-<version>`) | the session log whose `.session.lock` it holds open (else the runtime registry), else its pane title | `muse-session-file`, `muse-title` |
+| ZCode | `zcode-cli` (a Node process titled so) | nothing: sessions in SQLite, no title, no bell | — (hooks, else `process`) |
 | any of them, nothing else claiming | — | the process itself: `idle`, `done` with the bell | `process` |
 
-The order statusd takes them in: a hook sidecar > a Claude session file > a Kimi session file > the Grok Build
-observer (its session file, else its title) > the Grok Build title on a pane observed as `grok` > the Codex title (only
-where Codex can be) > the observed harness itself; the window bell turns an idle or finished turn into `done`. When
+The order statusd takes them in: a hook sidecar > a Claude session file > a Kimi session file > a Muse session file >
+the Grok Build observer (its session file, else its title) > the Grok Build title on a pane observed as `grok` > the
+Muse title on a pane observed as `muse` > the Codex title (only where Codex can be) > the observed harness itself; the
+window bell turns an idle or finished turn into `done`, except for Muse Code and ZCode, which ring none. When
 the walk names a harness, that is the published `harness` whatever signal decided the status. Check it:
 
 ```sh
-lanes doctor | grep '  lanes: '        # lanes: claude 50 · codex 20 · kimi 3 · grok 0 · grok-cli 0 · shell 0
+lanes doctor | grep '  lanes: '        # lanes: claude 50 · codex 20 · kimi 3 · grok 0 · grok-cli 0 · muse 1 · zcode 0 · shell 0
 jq '[.lanes[].agent.harness // empty] | group_by(.) | map({(.[0]): length}) | add' ~/.local/state/lanes/status.json
 ```
 
@@ -1092,7 +1121,8 @@ python3 -c 'import json,sys; a=json.load(open(sys.argv[1]))["lanes"][sys.argv[2]
 process), `cat $P/<pid>/task/*/children` lists its children, `cat $P/<child>/comm` names each and `readlink
 $P/<child>/exe` its file. A harness more than four levels below the pane is `unknown`; so is a pane whose tree holds
 anything but shells and no harness. Before 1.5.0 a Kimi lane read `codex / idle`: the title rule took any title of two
-or more words for Codex's (DEF-1970).
+or more words for Codex's (DEF-1970); before 1.6.0 a busy Muse Code lane read `codex / working`: the walk did not know
+Muse, and the Codex rule reads a braille spinner on an `unknown` pane (DEF-2030).
 
 ### Kimi Code
 
@@ -1202,6 +1232,76 @@ TERM and USER, so `lane-mcp` reads `LANE_ID`, `LANE_WS`, `TMUX` and `TMUX_PANE`
 `/proc/<pid>/environ`, and only when that parent process is a harness (DEF-1992). grok-cli sends no custom headers: its
 requests carry no trace.
 
+### Muse Code
+
+**Observed** (`libexec/harness_muse.py`, ARCHITECTURE "Muse Code and ZCode"). Muse Code 1.4.10 (Meta) runs as one
+process, `~/.local/bin/muse-bin-<version>`, exec'd by the launcher script `~/.local/bin/muse`. statusd joins the pane's
+Muse pid to its session through `/proc/<pid>/fd`: the live process holds `…/muse/sessions/YYYY/MM/DD/<id>/.session.lock`
+open, and the lock file says `pid=<pid>` (both MEASURED); else Muse's runtime registry,
+`~/.local/share/muse/runtime/muse/sessions/<id>.json`, whose `process_generation_hint` is `pid=<pid>` (deleted when Muse
+exits). It reads the last 64 KiB of that session's `session.jsonl` (whole lines only): an accepted prompt or a running
+turn is `working`; the turn's `terminal` completed or cancelled is `needs_input`, failed `errored`; `session.end`, or no
+write for an hour, makes no claim. The session's name (`session.name.changed`, near the log's start: read from its first 32 KiB when the tail holds none) is the task line. The `run started`
+record and the accepted-prompt record carry the person's prompt: the observer reads only their kinds and times, never
+their text. Without a usable log the title decides: `⠙ <workspace folder>` working, `<workspace folder>` idle. Muse
+rings no bell: a Muse lane is never `done` by the bell.
+
+To confirm a Muse lane is joined, in its container: `ls -l /proc/<muse pid>/fd | grep session.lock` names the session
+directory; `tail -c 2000 <that directory>/session.jsonl` ends with the turn's last record. Do not paste that file
+anywhere: its `run started` and `runtime.user_intent.accepted` records hold the prompt (customer content).
+
+**Hooks** (installed when the container has `~/.config/muse/`): `lanes hooks install --agent muse --container <name>`,
+then `--write`, merges the lane-signal groups into the `hooks` of `~/.config/muse/settings.json` (Claude Code's shape:
+`{Event: [{hooks: [{type: "command", command, timeout}]}]}`, timeout in seconds). A new file is created with
+`"schema_version": 1`; an existing file without it is refused (Muse refuses it too). Never registered:
+`PreLLMCall`/`PostLLMCall`, `SubagentStart`/`SubagentStop`, `PostToolBatch` (they carry model content and fire per
+call). `Interrupt` runs with `"async": true`, which Muse requires. **Muse clears a hook's environment** to HOME, PATH,
+TERM, LANG, LC_ALL, USER, LOGNAME, SHELL, TMPDIR, MUSE_SESSION_ID and MUSE_THREAD_ID (MEASURED): LANE_ID, LANE_WS, TMUX
+and TMUX_PANE do not arrive, so `lane-signal` reads them from the Muse process's own `/proc/<pid>/environ` (bounded,
+never through a link, and only when that pid is a known harness; DEF-2031). Muse does not run Claude Code's hooks or
+MCP servers.
+
+**MCP and trace.** `lane mcp install` writes `mcp_servers.lanes` into `~/.config/muse/settings.json`: `{"transport":
+"stdio", "command": "/home/coder/.lz/bin/lane-mcp", "args": [], "env": {"LANE_ID": "${LANE_ID:-}", "LANE_WS":
+"${LANE_WS:-}", "TMUX": "${TMUX:-}", "TMUX_PANE": "${TMUX_PANE:-}"}, "mode": "optional"}`. Muse starts a stdio server
+with a cleared environment plus the entry's `env`, and fills `${NAME:-}` from its own environment (MEASURED: the lane id
+arrived; an unset name arrived empty); `mode` `optional` keeps a failing `lane-mcp` from stopping the session (the
+default `required` would). Its MCP client name is `tbh` (MEASURED), which lane-mcp reads as `muse`. Every canonical
+recipe sets `MUSE_CUSTOM_HEADERS='x-throttle-trace: lanes/<ws>/<id>'`: MEASURED on 1.4.10 (the header arrived on Muse's
+`GET …/models`), but Meta does not document the variable, so a later Muse may drop it silently (DEF-2059): after a Muse
+update, check that the Throttle `muse-code` pool still sees `x-throttle-trace` from a lane.
+
+**Measurement hazard.** Muse 1.4.10 writes `~/.local/share/muse/session-name-authority/` under the account's home from
+the password database even when `HOME` points elsewhere (MEASURED 2026-10-16 in a scratch-HOME run: it created
+`authority.json` and `session-names.db` in the real home). Anyone measuring Muse in a scratch HOME must remove that
+directory afterwards.
+
+**Not captured yet (needs_operator_capture, DEF-2057):** the session-log records of a turn that waits for an approval
+and of a failed turn. The observer reads a failed `terminal` as `errored` and an approval only from a record kind that
+names one; until a logged-in capture exists, the hooks are the approval signal.
+
+### ZCode
+
+ZCode CLI (Z.ai, `zai-org/ZCode` apps/zcode-cli 0.16.9; read in its source and README, not run here) is a Node program
+that sets its process title to `zcode-cli` (its `comm`). It keeps its sessions in SQLite (`~/.zcode/cli/db/db.sqlite`)
+and draws no title and no bell, so Lanes observes only its process: a ZCode lane without hooks is `zcode` / `idle`
+(`source: process`).
+
+**Hooks** (installed when the container has `~/.zcode/`): `lanes hooks install --agent zcode --container <name>`, then
+`--write`. ZCode's hooks are off by default; the install sets `hooks.enabled` to true in `~/.zcode/cli/config.json` and
+merges `process` hooks into `hooks.events` (`{type: "process", command: "/home/coder/.lz/bin/lane-signal", args:
+["working", "--event", "PreToolUse", "--harness", "zcode"], timeoutMs: 2000}`; ZCode runs argv without a shell, so the
+path is absolute). A file whose `hooks.enabled` is explicitly false refuses: someone turned hooks off, and Lanes does not
+turn them on behind them. ZCode runs no `Stop` after an interrupt: an interrupted tool's `PostToolUseFailure` carries
+`is_interrupt: true`, which lane-signal records as `needs_input`; an interrupt while the model streams is not seen
+(DEF-2091). Hooks inherit ZCode's environment plus `ZCODE_SESSION_ID`, so the lane identity arrives directly.
+
+**MCP, no trace.** `lane mcp install` writes `mcp.servers.lanes` = `{"type": "stdio", "command":
+"/home/coder/.lz/bin/lane-mcp"}`; ZCode's stdio servers inherit its environment. A file with `features.mcp` false is
+left alone. ZCode's client name is read as `zcode` when it starts with `zcode` (INFERRED from its source, DEF-2060).
+ZCode sends only the fixed `api.headers` of its configuration: there is no per-process header, so its requests carry
+no lanes trace.
+
 ### Throttle-side notes
 
 A trace only matters for a harness attached to a Throttle pool; a running lane gets the recipe's trace variables when
@@ -1211,7 +1311,10 @@ it is next created.
 and `/pools/kimi/status` when tokened), but an update only ships the new `throttle-pulse` file: `lanes
 install-container` starts nothing while the `pulse` session runs, so the 1.4.0 loop keeps running and the sidebar's
 `◆ moonshot` row says `no data` (`lanes doctor`: `kimi ?`) until it is restarted (DEF-2003): `docker exec -u 1000
-<container> tmux -L lanes-pulse kill-session -t pulse`, then `lanes install-container <container>`.
+<container> tmux -L lanes-pulse kill-session -t pulse`, then `lanes install-container <container>`. The same holds for
+1.6.0's `muse-code` and `zai` pools (the `◆ meta` and `◆ z.ai` rows; `lanes doctor`: `muse-code ? · zai ?`). A daemon
+from before Throttle's native `muse-code` and `zai` pools answers 404 on their routes: those rows then say `no data`
+too, which is no fault of Lanes.
 
 **Throttle-side items (the Throttle provider lane's; filed, not built in Lanes):**
 
@@ -1229,6 +1332,12 @@ install-container` starts nothing while the `pulse` session runs, so the 1.4.0 l
   Attaching it is a Throttle step (`throttle accounts add <name> --provider kimi --pool kimi`, then `throttle setup
   --install-clients`; the [`throttle-kimi-provider`](../../skills/throttle-kimi-provider/SKILL.md) skill), outside
   Lanes.
+- **Muse Code and ZCode attachment (Throttle side, not Lanes):** Throttle has no managed Muse CLI attachment, so a Muse
+  lane's requests reach Throttle's `muse-code` pool only if the operator points Muse at it; Claude Code reaches either
+  pool through `throttle sessions start --claude --pool muse-code|zai`. ZCode is attached by `throttle setup
+  --install-clients` after the first Z.ai account (the managed `throttle-zai` rule in `~/.zcode/v2/provider_config.json`).
+  See the [`throttle-muse-code-provider`](../../skills/throttle-muse-code-provider/SKILL.md) and
+  [`throttle-zai-provider`](../../skills/throttle-zai-provider/SKILL.md) skills.
 
 ## The agents' MCP entries (`lane-mcp`, on by default)
 

package/payload/lanes/docs/USERGUIDE.md

@@ -1656,8 +1656,8 @@ Names must be non-empty and free of control characters. The id, resolve file and
   each container running, the statusd heartbeat, all registry lanes observed and present (stale lanes counted as
   "shown with their last known state"), the process table, no host-side tmux servers, coexistence mode, Zellij
   reachable, phone picker panes current, and the host not under critical memory pressure.
-- Information: the harness mix (1.5.0, [Harnesses](#harnesses)): `lanes: claude 50 · codex 20 · kimi 3 · grok 0 ·
-  grok-cli 0 · shell 0`, from each lane's `agent.harness` (`unknown` only when a lane has it; a lane with no agent is
+- Information: the harness mix (1.5.0; muse and zcode 1.6.0, [Harnesses](#harnesses)): `lanes: claude 50 · codex 20 · kimi
+  3 · grok 0 · grok-cli 0 · muse 1 · zcode 0 · shell 0`, from each lane's `agent.harness` (`unknown` only when a lane has it; a lane with no agent is
   not counted; `shell` stays 0 in practice: a lane whose harness ended into its shell is published under that
   harness's name with the status `shell`); lanes per create-recipe class (`idempotent`, `attach-only`, `null`, `external`, `retired-path`), how many
   create with their identity, where the `lane` contract is installed, zmx-held lanes, the preview renderer, the live
@@ -1723,12 +1723,14 @@ anything, picks the first signal that applies:
    turn keep it, unless the report was `working`.
 2. A **Claude Code session file** `~/.claude/sessions/<pid>.json` naming the pane, for a live pid (recycled pids are
    rejected).
-3. **Kimi Code's session files**, then **Grok Build's** (which session the pane's `grok` runs, its event log, else its
-   pane title), for a pane whose process is that harness ([Harnesses](#harnesses)).
+3. **Kimi Code's session files**, then **Muse Code's** (the session log of the Muse process the pane runs), then
+   **Grok Build's** (which session the pane's `grok` runs, its event log, else its pane title), then **Muse Code's
+   pane title**, for a pane whose process is that harness ([Harnesses](#harnesses)).
 4. The **Codex pane title**, only where Codex can run: `[ ! ] Action Required` is needs approval, a braille spinner is
    working, a task title is idle.
 5. The **harness process itself**: nothing above claimed the pane, so it is the harness the pane runs, idle.
-6. The **window bell**, throughout: an idle lane or a finished turn plus a bell is done.
+6. The **window bell**, throughout: an idle lane or a finished turn plus a bell is done. Muse Code and ZCode ring no
+   bell, so a bell never makes their lane done.
 
 A Codex title left on a bare shell with no child process, or a Grok Build title over a pane that runs only shells, is
 `shell` (the harness ended). Since 1.5.0 the harness itself is observed, not guessed: see [Harnesses](#harnesses).
@@ -1747,14 +1749,17 @@ A Codex approval read from its pane title (a lane without hooks) keeps the same
 ### Harnesses
 
 Lanes 1.5.0 (W12, [spec](../../docs/superpowers/specs/2026-10-15-lanes-harness-observers-design.md)) reads five agent
-harnesses: Claude Code, Codex, Kimi Code, Grok Build (xAI's official `grok`) and grok-cli (the community `grok`).
+harnesses: Claude Code, Codex, Kimi Code, Grok Build (xAI's official `grok`) and grok-cli (the community `grok`);
+Lanes 1.6.0 (W13, [spec](../../docs/superpowers/specs/2026-10-16-lanes-harness-observers-muse-zcode-design.md)) adds
+Muse Code (Meta's `muse`) and ZCode (Z.ai's `zcode`).
 Which one runs in a lane is an **observed fact**: statusd walks the pane's process tree (plain `/proc` reads, no new
-process) and publishes `agent.harness` as `claude`, `codex`, `kimi` (Kimi Code), `grok` (Grok Build), `grok-cli` or
-`unknown`; a pane that runs only shells is `shell` to the walk and shows no agent of its own (or the harness that ended
-there, with the status shell). A pane title that looks like Codex's is read as Codex only where Codex runs: before 1.5.0 any
-title of two or more words read as an idle Codex, so a Kimi lane showed `codex / idle`. `lanes doctor` prints the mix:
-`lanes: claude 50 · codex 20 · kimi 3 · grok 0 · grok-cli 0 · shell 0`. Each harness gets the lane-signal hooks, the
-Lanes MCP server and the Throttle trace its own files allow:
+process) and publishes `agent.harness` as `claude`, `codex`, `kimi` (Kimi Code), `grok` (Grok Build), `grok-cli`,
+`muse` (Muse Code), `zcode` (ZCode) or `unknown`; a pane that runs only shells is `shell` to the walk and shows no agent
+of its own (or the harness that ended there, with the status shell). A pane title that looks like Codex's is read as
+Codex only where Codex runs: before 1.5.0 any title of two or more words read as an idle Codex, so a Kimi lane showed
+`codex / idle`, and before 1.6.0 a busy Muse Code lane (its spinner title `⠙ <folder>`) showed `codex / working`.
+`lanes doctor` prints the mix: `lanes: claude 50 · codex 20 · kimi 3 · grok 0 · grok-cli 0 · muse 1 · zcode 0 · shell
+0`. Each harness gets the lane-signal hooks, the Lanes MCP server and the Throttle trace its own files allow:
 
 | Harness | What Lanes reads with no hooks (observed) | Hooks (`lanes hooks install --agent …`, a dry run until `--write`) | MCP server |
 | --- | --- | --- | --- |
@@ -1763,6 +1768,8 @@ Lanes MCP server and the Throttle trace its own files allow:
 | Kimi Code 2.1.1 | its session files: `~/.kimi-code/sessions/wd_*/session_<uuid>/state.json` and the last 64 KiB of `agents/main/wire.jsonl` | `--agent kimi`: a `# >>> lanes hooks >>>` block of `[[hooks]]` in `~/.kimi-code/config.toml` | `~/.kimi-code/mcp.json` |
 | Grok Build 1.0.52 | `$GROK_HOME/active_sessions.json` (which pid runs which session), the session's `events.jsonl` and `summary.json` (its title), the pane title | `--agent grok`: `~/.grok-build/hooks/lanes.json` plus blocks in `~/.grok-build/config.toml` | a `# >>> lanes mcp >>>` block in `~/.grok-build/config.toml` |
 | grok-cli 1.1.7 | nothing: it sets no title and rings no bell | `--agent grok-cli`: `hooks` in `~/.grok/user-settings.json` | the `mcp.servers` item `lanes` in `~/.grok/user-settings.json` |
+| Muse Code 1.4.10 | its session log `~/.local/share/muse/sessions/YYYY/MM/DD/<id>/session.jsonl` (the last 64 KiB; the session is the one whose `.session.lock` the lane's Muse process holds open), the pane title | `--agent muse`: `hooks` in `~/.config/muse/settings.json` | `mcp_servers.lanes` in `~/.config/muse/settings.json` |
+| ZCode (zcode-cli 0.16.9) | only its process: it keeps its sessions in a database and sets no title or bell | `--agent zcode`: `hooks.events` (and `hooks.enabled`) in `~/.zcode/cli/config.json` | `mcp.servers.lanes` in `~/.zcode/cli/config.json` |
 
 Per container, on the server (each a dry run that prints its diff until `--write`):
 
@@ -1770,9 +1777,11 @@ Per container, on the server (each a dry run that prints its diff until `--write
 lanes hooks install --agent kimi --container <name> --write       # Kimi Code: ~/.kimi-code/config.toml
 lanes hooks install --agent grok --container <name> --write       # Grok Build: ~/.grok-build/hooks/lanes.json, config.toml
 lanes hooks install --agent grok-cli --container <name> --write   # grok-cli: ~/.grok/user-settings.json
+lanes hooks install --agent muse --container <name> --write       # Muse Code: ~/.config/muse/settings.json
+lanes hooks install --agent zcode --container <name> --write      # ZCode: ~/.zcode/cli/config.json
 ```
 
-What the hooks of the three newer harnesses give the boards (Claude Code's and Codex's: "Hooks" below):
+What the hooks of the five newer harnesses give the boards (Claude Code's and Codex's: "Hooks" below):
 
 | Harness | Event | Status |
 | --- | --- | --- |
@@ -1788,6 +1797,15 @@ What the hooks of the three newer harnesses give the boards (Claude Code's and C
 | Grok Build | `SessionStart` / `SessionEnd` | idle / shell |
 | grok-cli | `UserPromptSubmit`, `PreToolUse`, `PostToolUse` | working |
 | grok-cli | `Stop` / `StopFailure` / `SessionEnd` | needs_input / errored / shell |
+| Muse Code | `UserPromptSubmit`, `PreToolUse`, `PostToolUse`, `PostToolUseFailure` | working |
+| Muse Code | `PermissionRequest`, `Notification` | needs_approval |
+| Muse Code | `Stop`, `Interrupt` | needs_input |
+| Muse Code | `StopFailure` | errored |
+| Muse Code | `SessionStart` / `SessionEnd` | idle / shell |
+| ZCode | `UserPromptSubmit`, `PreToolUse`, `PostToolUse` | working |
+| ZCode | `PostToolUseFailure` | working; needs_input when the person interrupted the tool |
+| ZCode | `PermissionRequest` | needs_approval |
+| ZCode | `Stop` / `SessionStart` | needs_input / idle |
 
 **Kimi Code** comes from its own installer (`~/.kimi-code`). Without hooks, a Kimi session is joined to its lane by
 working folder: the lane's Kimi process whose folder is the session's `cwd`, newest `updatedAt` first. Two Kimi lanes
@@ -1824,22 +1842,51 @@ there.
 **grok-cli** comes from its own installer (`~/.grok`) and has hooks only, with exact-string matchers. It has no
 approval signal and no title or bell: its lane shows working, needs input, errored or shell, never needs approval.
 
+**Muse Code** comes from Meta's installer (`~/.local/bin/muse`, which runs `muse-bin-<version>`; its settings in
+`~/.config/muse`). Without hooks, statusd joins the lane's Muse process to its session through the session's
+`.session.lock`, which the live process holds open (else Muse's runtime registry), and reads the end of
+`session.jsonl`: an accepted prompt or a running turn is working; a completed or cancelled turn is needs input; a
+failed turn is errored; a session that ended (`session.end`) or that wrote nothing for an hour says nothing. The
+session's name (two words such as `velvet-pollux`, or the one you gave it) is the lane's task line; Lanes never reads
+or publishes your prompt. Without a readable log, the title decides: `⠙ <folder>` is working, `<folder>` idle. Muse
+rings no bell. Muse runs its hooks with a cleared environment (no `LANE_ID`, no `TMUX`), so `lane-signal` finds the lane
+in the environment of the Muse process itself. The hooks install requires (and creates in a new file)
+`"schema_version": 1`; it never registers the per-model-call, subagent or tool-batch events, and `Interrupt` runs
+`async` as Muse requires. An approval in Muse's own log was not captured yet: until it is, the hooks
+(`PermissionRequest`, `Notification`) are what shows needs approval.
+
+**ZCode** comes from Z.ai's installer (`~/.zcode`). Lanes reads nothing of its own files: it keeps sessions in a
+database and draws no title or bell, so a ZCode lane without hooks shows `zcode / idle`. Its hooks are off by default:
+`lanes hooks install --agent zcode` sets `hooks.enabled` to true and adds `process` hooks (the absolute path of
+`lane-signal` and its arguments, a 2 s timeout); a file where someone set `hooks.enabled` to false is left alone. ZCode
+runs no `Stop` hook after you interrupt a turn: an interrupted tool reports needs input through `PostToolUseFailure`,
+and an interrupt while the model streams is not seen.
+
 **Agent tools (MCP).** `~/.lz/bin/lane mcp install` (which `lanes install-container` runs, or `lane mcp install
---agent kimi|grok|grok-cli`) writes the Lanes server into each harness's file in the table above: Kimi Code's
+--agent kimi|grok|grok-cli|muse|zcode`) writes the Lanes server into each harness's file in the table above: Kimi Code's
 `~/.kimi-code/mcp.json` (the Claude `mcpServers` shape), Grok Build's `[mcp_servers.lanes]` as a marked block (its
 `[compat.claude] mcps = false` keeps `lane-mcp` from starting twice; Grok Build passes its session id to the server),
 and grok-cli's `mcp.servers`. grok-cli starts MCP servers with a stripped environment, so `lanes_whoami` reads the
-lane's identity from the environment of the grok-cli process that started it.
+lane's identity from the environment of the grok-cli process that started it. Muse Code also clears a server's
+environment, so its entry passes `LANE_ID`, `LANE_WS`, `TMUX` and `TMUX_PANE` as `${NAME:-}` (Muse fills them from its
+own environment) and is `"mode": "optional"` (Muse's default `required` would stop the session if `lane-mcp` could not
+start); its file must already say `"schema_version": 1`. ZCode's servers inherit its environment; a file with
+`features.mcp` false is left alone.
 
 **The Throttle trace.** Kimi Code blanks `ANTHROPIC_CUSTOM_HEADERS`, so every recipe that sets it also sets
 `KIMI_CODE_CUSTOM_HEADERS='x-throttle-trace: lanes/<ws>/<id>'`. Grok Build's global extra headers would trace every
 lane alike, so recipes export `LANES_TRACE` and its hooks install writes `env_http_headers = {"x-throttle-trace" =
 "LANES_TRACE"}` for its built-in models `grok-4.6` and `grok-4.5`. grok-cli sends no custom headers: its requests carry
-no trace. A trace only matters for a harness attached to a Throttle pool: Kimi Code when `throttle setup
---install-clients` attached it, Grok not at all (Throttle has no xAI pool).
+no trace. Muse Code sends the headers of `MUSE_CUSTOM_HEADERS` (measured on 1.4.10, not documented by Meta), so every
+recipe also sets `MUSE_CUSTOM_HEADERS='x-throttle-trace: lanes/<ws>/<id>'`. ZCode has only fixed headers in its
+configuration: its requests carry no trace. A trace only matters for a harness attached to a Throttle pool: Kimi Code
+when `throttle setup --install-clients` attached it, Muse Code and ZCode once attached to Throttle's `muse-code` and
+`zai` pools, Grok not at all (Throttle has no xAI pool).
 
 **Files Lanes changes.** Each is kept as `<file>.bak-<UTC>` first. In a TOML file Lanes changes only its marked block,
-so to undo, delete the block. The diff a dry run prints shows a credential's value (grok-cli's `apiKey`) as `…`.
+so to undo, delete the block; in Muse Code's and ZCode's JSON files it changes only the one member it names (`hooks`,
+`mcp_servers.lanes`, `hooks.events`, `mcp.servers.lanes`), every other byte kept. The diff a dry run prints shows a
+credential's value (grok-cli's `apiKey`) as `…`.
 `lane-signal` without `--harness` takes the harness from `LANE_HARNESS`, else from the agent process above it, else
 records `unknown`.
 
@@ -1860,7 +1907,7 @@ lanes onboard anna --container ws-anna --workspace anna-tools --repo /home/coder
 | Board | A workspace tab for the repository (`lanes workspaces add`, section 6) on every device's view |
 | Contract | `lane`, `lane-run`, `lane-signal`, `lane-edit`, the quick-edit `vimrc`, `lane-mcp` and the hook definitions in the container's `~/.lz` (`lanes install-container`) |
 | Agent tools | The Lanes MCP server in Claude Code's and Codex's configuration, so an agent can see the lanes around it ("Agent tools (MCP)" below) |
-| Hooks | The lane-signal hooks for Claude Code and Codex ("Hooks" below), and for Kimi Code, Grok Build and grok-cli where they are installed ([Harnesses](#harnesses)), so the sidebar's agent glyphs are event-driven |
+| Hooks | The lane-signal hooks for Claude Code and Codex ("Hooks" below), and for Kimi Code, Grok Build, grok-cli, Muse Code and ZCode where they are installed ([Harnesses](#harnesses)), so the sidebar's agent glyphs are event-driven |
 | Throttle | `throttle setup --install-clients` inside the container when Throttle is installed and configured there, so the agents' requests go through the pool; otherwise the one-time setup to run on a terminal is printed (a first setup signs in, which needs a person; Lanes runs without Throttle) |
 | Recipes | `lanes cursor-sync <id> --canonicalize --write` when the repository has a `.vscode/terminals.json`: each lane's create recipe gives it its identity and trace ("Lane identity" below) |
 | Sync and doctor | The registry knows the new lanes; `lanes doctor`'s result is reported, never fatal |
@@ -1888,8 +1935,8 @@ lanes hooks install --agent claude --container <name> --write    # applies it (b
 lanes hooks install --agent codex --container <name> --write     # ~/.codex/hooks.json (+ notify in config.toml)
 ```
 
-`lanes hooks install --agent claude|codex|kimi|grok|grok-cli (--container <name> | --home <dir>) [--dry-run | --write]`
-is a dry run unless `--write` (Kimi Code, Grok Build and grok-cli: [Harnesses](#harnesses)); your own hooks and
+`lanes hooks install --agent claude|codex|kimi|grok|grok-cli|muse|zcode (--container <name> | --home <dir>) [--dry-run | --write]`
+is a dry run unless `--write` (Kimi Code, Grok Build, grok-cli, Muse Code and ZCode: [Harnesses](#harnesses)); your own hooks and
 keys stay, and an earlier lane-signal install is replaced, not duplicated. An install that is already current is
 left where it is, even when another tool (Throttle's `setup --install-clients`) has put its own group before or
 after it or re-sorted the file's keys, so running it again writes nothing. For
@@ -1931,7 +1978,7 @@ verbs, so the holder stays swappable.
 | `lane kill <id> --yes [--force]` | End the lane (the only verb that ends an agent); refuses while the hook sidecar says `working` unless `--force` |
 | `lane new <id> [--ws W] [--title T] [--cwd DIR] [--icon I] [--color C] -- <command…>` | Create a zmx-held lane |
 | `lane gc --sockets` | Unlink this container's tmux socket files that tmux is refused on (no server listens); a live, empty or silent server keeps its file |
-| `lane mcp install [--agent claude\|codex\|kimi\|grok\|grok-cli\|all] [--write]` | Add the Lanes MCP server to `~/.claude.json` and `~/.codex/config.toml`, and to Kimi Code's, Grok Build's and grok-cli's files where they are installed ("Agent tools (MCP)" below); a dry run until `--write` |
+| `lane mcp install [--agent claude\|codex\|kimi\|grok\|grok-cli\|muse\|zcode\|all] [--write]` | Add the Lanes MCP server to `~/.claude.json` and `~/.codex/config.toml`, and to Kimi Code's, Grok Build's, grok-cli's, Muse Code's and ZCode's files where they are installed ("Agent tools (MCP)" below); a dry run until `--write` |
 | `lane publish <file> [--title T] [--for <login>] [--kind md\|html\|svg\|file]` | Put a file of this container on the docs page from the lane it runs in ("Publish to the docs page" below); prints the request as JSON |
 
 Every tmux client these verbs start runs with `-N`, so none of them can start a tmux server: an attach to a lane
@@ -1974,7 +2021,7 @@ only read:
 | Tool | Answers |
 | --- | --- |
 | `lanes_whoami` | Which lane the agent runs in: id, board, name, kind (declared, registered or unregistered), tmux socket and session. It comes from `LANE_ID`, else from the agent's own tmux pane. Outside a lane the answer is `lane: null` with the reason |
-| `lanes_list` | Every lane in this container with its state and its agent (harness, status, task). Filters: `workspace`, `needs_you: true` (needs approval, errored or needs input, the sidebar's "Needs you" section) and `agent` (`any`, `none`, `claude`, `codex`, `kimi`, `grok` for Grok Build, `grok-cli`). `status.fresh` is false once the host's observation is more than 60 s old |
+| `lanes_list` | Every lane in this container with its state and its agent (harness, status, task). Filters: `workspace`, `needs_you: true` (needs approval, errored or needs input, the sidebar's "Needs you" section) and `agent` (`any`, `none`, `claude`, `codex`, `kimi`, `grok` for Grok Build, `grok-cli`, `muse` for Muse Code, `zcode` for ZCode). `status.fresh` is false once the host's observation is more than 60 s old |
 | `lanes_status` | One lane in full: what the registry says, the observed state and agent, whether its tmux session is alive now (`null` when tmux does not answer in 5 s) and its hook sidecar |
 | `lanes_capture` | The last `lines` (1 to 500, default 100) non-blank lines of a lane's screen and scrollback, as plain text. Any lane of the container can be read |
 
@@ -2084,8 +2131,8 @@ zmx lane's agent state yet (DEF-1573). Gate results: [ZMX-RING0.md](ZMX-RING0.md
 
 The sidebar's free rows hold a pinned health block (Lanes 1.4.0, W11): on panes of 18 rows or more, once the server's
 statusd publishes the fleet facts, it sits above the upload strip and the lane list scrolls in the rows left. It is
-live (statusd rewrites it at most every 10 s), local, and needs no collector. At 25 rows or more it is a rule and six
-rows (1.5.0 added the Kimi pool's row; 1.4.0 drew five from 24 rows):
+live (statusd rewrites it at most every 10 s), local, and needs no collector. At 27 rows or more it is a rule and eight
+rows (1.6.0 added Throttle's Muse Code and Z.ai pools' rows; 1.5.0 the Kimi pool's; 1.4.0 drew five from 24 rows):
 
 ```
  ── fleet ──────────────────────────
@@ -2093,6 +2140,8 @@ rows (1.5.0 added the Kimi pool's row; 1.4.0 drew five from 24 rows):
  ◆ anthropic ▰▰▰▰▰▰▱▱▱▱ 12/19 · wk 61% · reset 2h
  ◆ openai    ▰▰▰▱▱▱▱▱▱▱ 3/5 · 5h 28%
  ◆ moonshot  ▰▰▰▰▰▰▱▪▪· 5/8 · wk 44% · 5h 12%
+ ◆ meta      ▰▰▰▰▰▰▰▱▪· 6/9 · wk 52% · 5h 31%
+ ◆ z.ai      ▰▰▰▰▰▰▰▪▪· 4/6 · wk 47% · 5h 22%
  ▣ productbox cpu 42% · mem 61% · load 37 · psi 3%
  ▣ bw-tools 15G · worlds 9G · sakio 4G
 ```
@@ -2100,11 +2149,11 @@ rows (1.5.0 added the Kimi pool's row; 1.4.0 drew five from 24 rows):
 | Row | What it shows |
 | --- | --- |
 | `⚙ throttle` | One line for the Throttle pool: with the opt-in token, overflow spend today against the daily cap, new 429s and the spill fraction — one pool's figure, never a sum: the Anthropic and OpenAI overflow budgets are separate money, so the row shows the pool nearest its cap, one at its alert level first (Kimi has no paid overflow, so its pool never gives the money); without the token ` ⚙ throttle  up · spill 76% · 429 +4`, and ` down` in red when the daemon does not answer |
-| `◆ anthropic`, `◆ openai`, `◆ moonshot` | One availability bar per provider pool — Claude, Codex and (1.5.0) Kimi Code's, whose vendor is Moonshot AI: ten cells of usable `▰`, cooling `▱`, benched `▪` and dead `·` accounts (ASCII `=` `~` `:` `.`), then the usable count of the configured ones (` ◆ anthropic ▰▰▰▰▰▰▱▪·· 12/19`), then — with the token — the worst weekly or 5-hour burn and the soonest reset. A daemon with no Kimi account shows ` ◆ moonshot  ·········· 0/0`, which is no alarm; `no data` means the pulse did not report the pool (a pulse from before 1.5.0 still running: [RUNBOOK](RUNBOOK.md#harnesses)). There is no Grok row: Throttle has no xAI pool |
+| `◆ anthropic`, `◆ openai`, `◆ moonshot`, `◆ meta`, `◆ z.ai` | One availability bar per provider pool — Claude, Codex, (1.5.0) Kimi Code's, whose vendor is Moonshot AI, and (1.6.0) Throttle's `muse-code` (Meta's Muse Code) and `zai` (Z.ai) pools: ten cells of usable `▰`, cooling `▱`, benched `▪` and dead `·` accounts (ASCII `=` `~` `:` `.`), then the usable count of the configured ones (` ◆ anthropic ▰▰▰▰▰▰▱▪·· 12/19`), then — with the token — the worst weekly or 5-hour burn and the soonest reset. A daemon with no Kimi account shows ` ◆ moonshot  ·········· 0/0`, which is no alarm (the same for no Muse Code or Z.ai account); `no data` means the pulse did not report the pool (a pulse from before 1.5.0, or 1.6.0 for `meta` and `z.ai`, still running, or a daemon without that pool: [RUNBOOK](RUNBOOK.md#harnesses)). Kimi, Muse Code and Z.ai have no paid overflow, so their pools never give the Throttle row's money. There is no Grok row: Throttle has no xAI pool |
 | `▣ productbox` | The host: CPU and memory utilization, the 1-minute load, the highest pressure (PSI) figure |
 | `▣ <container> …` | The three workspace containers using the most memory |
 
-At 18–24 rows the block is three rows — Throttle, the provider with the smallest usable share (a pool with nothing
+At 18–26 rows the block is three rows — Throttle, the provider with the smallest usable share (a pool with nothing
 configured is never that one), the host — and smaller panes show none. Parts that do not fit are dropped from the end. A row turns amber when overflow spend reaches its alert
 level, a provider has no usable account, memory is fully stalled, memory use reaches 90 % or the CPU 95 % (its lead
 mark turns amber even when that part was dropped); red when the daemon does not answer. The whole block is dim, with a
@@ -2387,7 +2436,7 @@ Clients also get `lanes-helper.service` and `lanes-upload.path`/`.service` (Linu
 | Editor | `lanes cursor-commit [ws…] [--push]` | Section 6 |
 | Containers | `lanes install-container <name> [--no-mcp]` | Install the `lane` contract (section 2) and the agents' MCP entries for `lane-mcp` (section 7, "Agent tools (MCP)"); `--no-mcp` leaves both out |
 | Containers | `lanes onboard <login> --container <name> [--workspace <id> --repo <path> [--title T]] [--write] [--no-mcp]` | One user's container in one command: board, contract, Claude and Codex hooks, Throttle attachment, canonical recipes, sync, doctor, and a receipt (a dry run until `--write`; section 2) |
-| Containers | `lanes hooks install --agent claude\|codex\|kimi\|grok\|grok-cli (--container <name> \| --home <dir>) [--dry-run \| --write]` | Section 7 ([Harnesses](#harnesses)) |
+| Containers | `lanes hooks install --agent claude\|codex\|kimi\|grok\|grok-cli\|muse\|zcode (--container <name> \| --home <dir>) [--dry-run \| --write]` | Section 7 ([Harnesses](#harnesses)) |
 | Uploads | `lanes upload <ws> \| --active <device> [--paste]` | Read a tar stream into that workspace's `uploads/` |
 | Uploads | `lanes docs push <id>` | Print one docs-store document's receipt (any login's: you are the operator) and exit 2 `not configured`: the hook for the data service's publication surface, not built yet ([Docs](#docs)) |
 | Client | `lanes hello [device] [--client-version V]` | Prove path, key and server version; ` update=<version>` when V is older |

package/payload/lanes/install.sh

@@ -354,6 +354,7 @@ install_client() {
     fi
     chmod +x "$target/lanes-launch" "$target/lanes-window" "$target/lanes-upload"
     for name in lanes-launch lanes-window lanes-upload; do ln -sfn "$target/$name" "$bin/$name"; done
+    ln -sfn "$target/ghostty/lanes-themed-window" "$bin/lanes-themed-window"
     say "commands: lanes-launch, lanes-window, lanes-upload in $(tilde "$bin") ($([ "$link" = 1 ] && echo "linked to this checkout" || echo "copied to $(tilde "$target")"))"
     printf '%s\n' "$device" > "$config/device"
     say "device (view session) name: $device"
@@ -514,7 +515,7 @@ install_desktop() {
         return 0
     fi
     mkdir -p "$HOME/.local/share/applications"
-    sed "s|^Exec=.*|Exec=$bin/lanes-window|" "$target/omarchy/lanes.desktop" > "$HOME/.local/share/applications/lanes.desktop"
+    sed "s|^Exec=.*|Exec=$bin/lanes-themed-window|" "$target/omarchy/lanes.desktop" > "$HOME/.local/share/applications/lanes.desktop"
     # Hyprland (Omarchy): follow the LIVE config generation — Omarchy 4 = Lua, Omarchy 3 = hyprlang. One added
     # line, validated with `hyprctl configerrors`, and reverted automatically if Hyprland reports any error.
     hypr=$HOME/.config/hypr