CMUX runbooks: launch workers lean + socket needs no setup

Jobs/Delegate an initiative to a CMUX workspace.md

@@ -33,8 +33,9 @@ in `Initiatives/` (if not, run [[Run an initiative]] first) — that note is the
 delegated workspace's `backlog.md`.
 
 ## Steps
-1. **Preflight the socket.** `cmux identify --json` should succeed. If not, launch
-   CMUX and poll:
+1. **Confirm CMUX is up (routine — no setup).** The in-pane control socket works by
+   default; `cmux identify --json` is just a sanity-check. If CMUX isn't running,
+   launch it and poll:
    ```bash
    cmux identify --json >/dev/null 2>&1 || { open -a cmux; \
      for i in $(seq 1 30); do cmux identify --json >/dev/null 2>&1 && break; sleep 0.5; done; }
@@ -59,10 +60,14 @@ delegated workspace's `backlog.md`.
    task weight — a cheaper model for well-scoped execution, a more capable one
    for heavy reasoning):
    ```bash
-   cmux send --surface "$LEAD" "claude --model <model-id>"
+   cmux send --surface "$LEAD" "claude --model <model-id> --strict-mcp-config --mcp-config '{\"mcpServers\":{}}'"
    cmux send-key --surface "$LEAD" enter
    sleep 4
    ```
+   **Launch lean** — `--strict-mcp-config --mcp-config '{"mcpServers":{}}'` (if your
+   agent CLI supports it) gives the worker **few or no MCP servers**. A large MCP
+   fleet injects enough tool schema to crowd out a worker's context after a handful
+   of file reads. Add back only a server the task truly needs.
 6. **Kick it off with a one-line brief** that points at the vault note as its
    source of truth and demands a sentinel on completion. **One line, no newlines:**
    ```bash
@@ -95,8 +100,10 @@ delegated workspace's `backlog.md`.
   and reuse them — never guess a surface address.
 - **Notify ≠ done.** Always `read-screen` and confirm the sentinel; agents notify
   when they need input too.
-- **`socketControlMode: cmuxOnly` is fine** for an orchestrator running inside a
-  CMUX pane (the default). Only raise to `allowAll` if you drive from outside CMUX.
+- **No socket setup needed.** The default `socketControlMode: cmuxOnly` already lets
+  an in-pane orchestrator drive CMUX — that's this case, out of the box. You'd only
+  touch config (`allowAll`) to drive CMUX from *outside* a pane (a cron/scheduled
+  job, a plain terminal).
 - **One workspace = one repo context.** If the "delegation" is really N concurrent
   sub-tasks sharing one context, use panes instead → [[Spawn subagent panes in a CMUX workspace]].
 

Jobs/Spawn subagent panes in a CMUX workspace.md

@@ -31,8 +31,9 @@ split, the four-verb loop, model policy). **The lead coordinates — it does not
 the heavy editing itself once workers exist.**
 
 ## Steps
-1. **Know your own surface.** From the lead pane, `cmux identify --json` (socket
-   check) and `cmux list-pane-surfaces` to see the workspace + your surface ref.
+1. **Know your own surface.** From the lead pane, `cmux identify --json` (a routine
+   self-identify — the in-pane socket works by default, no setup) and
+   `cmux list-pane-surfaces` to see the workspace + your surface ref.
    Set `WS=<workspace_ref>` and `LEAD=<your surface_ref>`.
 2. **Split off worker panes** — anchor each split on an existing surface; capture
    each new ref. E.g. three workers:
@@ -48,11 +49,17 @@ the heavy editing itself once workers exist.**
    `send` the CLI line, then `send-key enter`, and give it a moment to boot:
    ```bash
    for S in "$W1" "$W2" "$W3"; do
-     cmux send --surface "$S" "claude --model <model-id>"
+     cmux send --surface "$S" "claude --model <model-id> --strict-mcp-config --mcp-config '{\"mcpServers\":{}}'"
      cmux send-key --surface "$S" enter
    done
    sleep 4
    ```
+   **Launch lean** — `--strict-mcp-config --mcp-config '{"mcpServers":{}}'` (if your
+   agent CLI supports it) gives each worker **few or no MCP servers**. A large MCP
+   fleet injects enough tool schema to crowd out a worker's context after ~a handful
+   of file reads — the same bloat that can make an in-process subagent/Task tool
+   unusable, which is why explicit pane workers are the reliable path. Add back only
+   a server the leg truly needs.
 5. **Dispatch one single-line task per worker**, each ending in a sentinel. **One
    line, no embedded newlines:**
    ```bash

meta/AGENTS.md

@@ -129,5 +129,11 @@ sharing a context — `Jobs/Spawn subagent panes in a CMUX workspace.md`). Both
 runbooks use the same four-verb control loop (type → submit → read → close),
 event-driven coordination (a `DONE: <summary>` sentinel — "notify" from the tool
 isn't the same as "done"), and a model policy of a more capable model as
-lead/orchestrator with cheaper/faster models as workers. Entirely optional —
-skip it if you're not running a multi-agent terminal tool.
+lead/orchestrator with cheaper/faster models as workers. **Launch pane workers
+lean** — give each worker few or no MCP servers (e.g. a `--strict-mcp-config`
+flag with an empty config, if your agent CLI supports it); a large MCP fleet
+injects enough tool schema to crowd out a worker's context after a handful of
+file reads, and that same bloat can make an in-process subagent/Task tool
+unusable — which is exactly why explicit, lean pane workers are the reliable
+path. Entirely optional — skip it if you're not running a multi-agent terminal
+tool.