Skip to Content
Pane Chat

Pane Chat is the global orchestrator terminal for a Pane workspace.

Normal agent tabs live inside a pane and usually map to one repository worktree. Pane Chat is different: it starts from the Pane data directory, outside any one repo, so it can coordinate the whole workspace.

Use it when you want to say things like:

Add this repo, create three worktree panes for these features, start Codex in each one, keep a review tab ready, and tell me when the PRs are ready to test.

What Pane Chat controls

Pane Chat can use the same runpane CLI contract that any agent can use:

runpane doctor --json
runpane agent-context --json
runpane repos list --json
runpane panes list --json
runpane panels list --pane <pane-id> --json
runpane panels output --panel <panel-id> --limit 200 --json

That gives it workspace-level visibility:

  • saved repositories
  • panes and their worktrees
  • terminal-backed tabs inside a pane
  • recent bounded terminal output
  • agent startup prompts
  • Pane data-directory and runtime mismatch diagnostics

Pane Chat does not need a Pane-specific MCP server. The terminal is the control plane, and runpane is the contract.

Claude or Codex

Pane Chat can run with Claude Code or Codex. The toggle in the top-right of Pane Chat switches the default orchestrator agent in Pane settings.

Both agents get the same local orchestration contract. Only the terminal command changes.

Local skills, not giant prompts

Pane keeps the startup prompt small:

Use the pane-orchestrator skill and initialize yourself as Pane Chat.

The actual workflow lives in local files under the Pane data directory:

<pane-dir>/.codex/skills/pane-orchestrator/SKILL.md
<pane-dir>/.claude/skills/pane-orchestrator/SKILL.md
<pane-dir>/skills/pane-chat/runpane-orchestrator.md
<pane-dir>/skills/pane-chat/runtime-context.md

Pane also caches the important workflow skills used by the orchestration loop, including discussion, plan/simple-plan, implement, implementation-reviewer, PR test automation, prepare-pr, investigate, and commit.

The cache is refreshed by Pane in the background, so Pane Chat can initialize from local files instead of fetching GitHub every time.

The workflow boundary

Pane Chat is the orchestrator, not the implementation worker.

For substantial work, greenfield projects, multi-agent work, and PR preparation, the default lifecycle is:

  1. Pane Chat discusses and clarifies intent with you.
  2. Pane Chat distills that discussion into a concise brief with constraints, success criteria, repo or worktree target, and autonomy level.
  3. A delegated agent creates a plan or simple-plan from that brief.
  4. A delegated implementation agent works from the approved plan artifact.
  5. A fresh review agent runs implementation review.
  6. PR test automation or prepare-pr runs after review passes.

This keeps discussion in one user-facing place while still letting specialized agents work in clean contexts.

Pane Chat can use judgment for very small, low-risk tasks. For broad or greenfield work, it should not treat a loose task brief as an implementation plan unless you explicitly ask it to skip planning.

Example flow

  1. Add a repository once in Pane.
  2. Open Pane Chat.
  3. Ask Pane Chat to create a feature pane.
  4. Pane Chat uses runpane panes create to create a worktree pane with the selected agent.
  5. The delegated agent plans the work inside that pane.
  6. After you approve the plan, Pane Chat delegates implementation in the same pane.
  7. Pane Chat opens fresh review or test tabs when the PR is ready.
  8. Pane Chat verifies results with runpane panels output, screen, or wait before reporting that work is done.

Why this matters

Most agent orchestration tools are tied to one supported agent or one hosted runtime. Pane Chat is agent-agnostic because it is just a terminal plus a local contract.

If a new CLI agent ships tomorrow, Pane can still run it in a pane. Pane Chat can still coordinate around it with runpane.

Related docs:

Last updated on
runpane CLIAgent Loops