916acd39e1
Per the skill convention, document /spawn-session (purpose, usage, how it wraps claude-tmux, gotchas) and index it in MEMORY.md. Claude-Session: https://claude.ai/code/session_014oa7T7z1h5n34vu8vX9zGT
1.9 KiB
/spawn-session
Purpose
Spawn a new, separate Claude Code session inside a detached tmux session with Remote
Control enabled, in a project's directory, named after the project (e.g. "Agent Runtimes",
auto-incrementing to "Agent Runtimes #2"). Lets the user start a session for another project
that persists on the host and is reachable later via tmux attach (over VPN) or driveable
from the Claude app.
Usage
/spawn-session <project>— spawn for a named project folder/spawn-session <project> --mode <mode>— override engagement mode/spawn-session <project> --attach— attach after spawning/spawn-session— lists projects and asks which one
How it works
Thin wrapper over the claude-tmux script (in small-scripts, symlinked to ~/sbin).
The skill only resolves the project name from $ARGUMENTS (or asks) and shells out to
claude-tmux <project> [flags]. All real logic — folder resolution, mode selection
(profile last-mode unless --mode), Title-Casing, #N auto-increment, tmux creation,
and launching claude --remote-control via claude-profile — lives in the script.
Gotchas
- Separate process, not a sub-agent. The spawned session does not share the current conversation's context. It's a full interactive Claude Code session the user drives.
- Remote Control only registers once
claudeis running. The script guarantees this by passing the engagement mode explicitly soclaude-profilenever stalls at its interactive picker. Don't "fix" the skill to omit the mode. - Default profile is
oreillyit-anthropic. Only override with--profileon request. - Concurrent same-profile sessions race on the shared
active-mode.env, but each session's cwd takes precedence for project auto-selection, so the right project is picked. - Spec + tests:
small-scripts/specs/claude-tmux.spec.md,tests/test-claude-tmux.sh.