* docs: condense CLAUDE.md for token efficiency Reduced CLAUDE.md from 223 to 169 lines (24% reduction). Changes: - Removed verbose sections (reference implementation table, redundant explanations) - Added "Key Files" section highlighting types.ts and plugin examples upfront - Condensed tech stack, conventions, and commands into scannable format - Kept critical content: plugin pattern, shell security, common mistakes Agents spawned by the orchestrator don't need special documentation - they just read the repo's existing CLAUDE.md. The orchestrator is transparent. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> * docs: comprehensively optimize CLAUDE.md and add package READMEs Major improvements to agent effectiveness on this codebase: ## Enhanced CLAUDE.md (169 → 444 lines) **New sections:** - Quick Start — get oriented fast (links to common tasks) - Looking for X? — quick reference table for finding code - Monorepo Tools — pnpm workspace commands (filter, watch mode, scoped builds) - Common Tasks — step-by-step guides (add plugin, add Session field, add event type) - Plugin Development — pattern explanation + examples (notifier-desktop, agent-claude-code) - Architecture Deep Dive — data flow diagram + state machine + key abstractions **Improved sections:** - Commands — added watch mode, filtering, scoped operations - Shell Security — added exploit example showing actual injection - Common Mistakes — added 5 code examples (BAD vs GOOD with explanations) - Design Decisions — added "Why" for each decision ## New Package READMEs (Progressive Disclosure) **packages/core/README.md:** - Explains core services (SessionManager, LifecycleManager, PluginRegistry) - Key files guide (types.ts, session-manager.ts, lifecycle-manager.ts) - Common tasks specific to core - Architecture notes (why flat metadata, why polling, why plugin slots) **packages/plugins/runtime-tmux/README.md:** - How the plugin works (creating sessions, sending messages, getting output) - Security considerations (session ID validation) - Common issues (tmux not installed, detached sessions persist) - Limitations (macOS/Linux only, no resource limits) - Architecture notes (why tmux over raw processes) ## Impact Agents working on this codebase now have: 1. **Faster discovery** — "Looking for X?" table + Quick Start links 2. **Actionable guides** — step-by-step for common tasks 3. **Concrete examples** — code showing actual mistakes and fixes 4. **Progressive disclosure** — package READMEs for deep dives 5. **Monorepo fluency** — pnpm workspace commands documented 6. **Architecture understanding** — data flow + state machine + "why" explanations Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| src | ||
| README.md | ||
| package.json | ||
| tsconfig.json | ||
README.md
@agent-orchestrator/plugin-runtime-tmux
Runtime plugin for executing agent sessions in tmux.
What This Does
Creates isolated tmux sessions for each agent. Each session runs in a separate tmux session with:
- Working directory set to workspace path
- Environment variables from config
- Agent launch command executed automatically
How It Works
Creating a Session
const handle = await runtime.create({
sessionId: "my-app-3",
workspacePath: "/Users/dev/.worktrees/my-app/my-app-3",
launchCommand: "claude -p 'Fix bug in auth module'",
environment: {
AO_SESSION_ID: "my-app-3",
AO_PROJECT_ID: "my-app",
},
});
What happens:
- Validates
sessionId(only alphanumeric, dash, underscore allowed) - Creates detached tmux session:
tmux new-session -d -s my-app-3 -c /path/to/workspace - Sets environment variables:
tmux ... -e KEY=VALUE - Sends launch command:
tmux send-keys -t my-app-3 "claude -p '...'" Enter - Returns RuntimeHandle with tmux session name
Sending Messages
await runtime.sendMessage(handle, "Fix the test failure in auth.test.ts");
What happens:
- Clears partial input:
tmux send-keys -t my-app-3 C-u - For short messages (<200 chars, no newlines): sends directly with
-lflag (literal mode) - For long/multiline messages: writes to temp file →
tmux load-buffer→tmux paste-buffer - Waits 300ms (let tmux process the text)
- Sends Enter:
tmux send-keys -t my-app-3 Enter
Why the complexity?
send-keyswithout-linterprets special strings ("Enter", "Space") as key names- Long strings can overflow tmux's command buffer
- Multiline strings need special handling
Getting Output
const output = await runtime.getOutput(handle, 50); // last 50 lines
Uses tmux capture-pane -t my-app-3 -p -S -50 to capture terminal buffer.
Checking if Alive
const alive = await runtime.isAlive(handle);
Uses tmux has-session -t my-app-3 (exit code 0 = exists, 1 = doesn't exist).
Destroying
await runtime.destroy(handle);
Kills tmux session: tmux kill-session -t my-app-3 (ignores errors if already dead).
Attaching to Sessions
For Terminal plugins (iTerm2, web):
const attachInfo = await runtime.getAttachInfo(handle);
// Returns: { type: "tmux", target: "my-app-3", command: "tmux attach -t my-app-3" }
Security
Session ID validation:
const SAFE_SESSION_ID = /^[a-zA-Z0-9_-]+$/;
Only allows safe characters. Prevents shell injection via session name (used in tmux commands).
Error Handling
- Session creation fails → cleans up (kills session) before throwing
- Message send fails → throws (caller should handle)
- Session already dead →
destroy()silently succeeds (idempotent)
Metrics
const metrics = await runtime.getMetrics(handle);
// Returns: { uptimeMs: 123456 }
Tracks uptime (stored in RuntimeHandle.data.createdAt).
Testing
This plugin is tested indirectly via packages/core/src/__tests__/tmux.test.ts (utility functions) and integration tests.
To test manually:
# Start a test session
tmux new-session -d -s test-session -c /tmp
tmux send-keys -t test-session "echo hello" Enter
# Capture output
tmux capture-pane -t test-session -p
# Kill session
tmux kill-session -t test-session
Common Issues
tmux not installed
If tmux is not in PATH, all operations fail. Install via:
- macOS:
brew install tmux - Linux:
apt-get install tmuxoryum install tmux
Session name conflicts
If a session with the same ID already exists, create() fails. The orchestrator should ensure unique session IDs.
Detached sessions persist after orchestrator crashes
tmux sessions keep running even if the orchestrator dies. Use tmux list-sessions to find orphans, tmux kill-session -t <name> to clean up.
Limitations
- macOS/Linux only — tmux is not available on Windows (use WSL)
- No Windows native support — use runtime-process instead on Windows
- Terminal buffer size —
getOutput()limited by tmux buffer size (default 2000 lines) - No resource limits — agents can consume unlimited CPU/memory (use docker/k8s runtimes for isolation)
Architecture Notes
Why tmux over raw processes?
- Sessions persist across orchestrator restarts
- Easy to attach for debugging:
tmux attach -t session-name - Terminal emulation (colors, ANSI codes work)
- Works well with interactive AI tools (Claude Code, Aider)
Why detached mode?
- Orchestrator doesn't block waiting for agent
- Multiple agents can run in parallel
- Humans can attach later without interrupting agent