agent-orchestrator/packages/plugins/runtime-tmux
prateek 8db5f2b161
docs: comprehensively optimize CLAUDE.md for agent effectiveness (#38)
* 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>
2026-02-15 03:34:35 +05:30
..
src Wire xterm.js terminal embed into web dashboard (#29) 2026-02-15 01:37:07 +05:30
README.md docs: comprehensively optimize CLAUDE.md for agent effectiveness (#38) 2026-02-15 03:34:35 +05:30
package.json feat: implement runtime and workspace plugins (tmux, process, worktree, clone) (#2) 2026-02-14 15:13:57 +05:30
tsconfig.json feat: scaffold TypeScript monorepo with all plugin interfaces 2026-02-13 17:02:42 +05:30

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:

  1. Validates sessionId (only alphanumeric, dash, underscore allowed)
  2. Creates detached tmux session: tmux new-session -d -s my-app-3 -c /path/to/workspace
  3. Sets environment variables: tmux ... -e KEY=VALUE
  4. Sends launch command: tmux send-keys -t my-app-3 "claude -p '...'" Enter
  5. Returns RuntimeHandle with tmux session name

Sending Messages

await runtime.sendMessage(handle, "Fix the test failure in auth.test.ts");

What happens:

  1. Clears partial input: tmux send-keys -t my-app-3 C-u
  2. For short messages (<200 chars, no newlines): sends directly with -l flag (literal mode)
  3. For long/multiline messages: writes to temp file → tmux load-buffertmux paste-buffer
  4. Waits 300ms (let tmux process the text)
  5. Sends Enter: tmux send-keys -t my-app-3 Enter

Why the complexity?

  • send-keys without -l interprets 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 deaddestroy() 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 tmux or yum 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 sizegetOutput() 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