# Pane Chat

Pane Chat is one conversation that controls your whole workspace.

Normal agent tabs sit inside a pane. They work on one repo, one branch. Pane Chat sits above all of that. It's an <Term id="orchestrator">orchestrator</Term>: it can see every repo you've added, every pane you've created, and every agent that's running.

Use it when you want to say something like:

> Add this repo, create three 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 it can do

Pane Chat uses the `runpane` CLI to control your workspace:

```bash
runpane repos list --json
runpane panes list --json
runpane panes create ...
runpane panels list --pane <pane-id> --json
runpane panels output --panel <panel-id> --limit 200 --json
```

That means it can:

- See which repos you've added
- See all your panes and their worktrees
- Read recent terminal output from any tab
- Create new panes and start agents in them
- Check what's running and what's waiting for input

No <Term id="mcp">MCP</Term> server needed. It's all just terminal commands.

## How it knows when a pane needs it

Pane Chat doesn't poll. At session start it arms a watcher, a stream of one line per event from Pane's daemon, and reads its panes only when a line says something changed: an agent finished a turn, an agent is waiting on you, a pane went idle, a tab exited, a pane was archived.

Every line wakes Pane Chat and replays its whole conversation, so the watcher is armed with the cost-conscious flags, not the bare defaults:

```bash
runpane watch --self-test
runpane watch --follow --kinds agent.ready,agent.blocked,agent.idle,panel.exited,pane.gone --settle 180000 --blocked-settle 30000 --min-interval 600000 --idle-backoff
```

You don't run these; Pane Chat does, automatically. The effect is that a finished turn is acted on within thirteen minutes at most, a pane waiting on you is reported within thirty seconds, and an overnight run doesn't burn your usage cap on wake-ups that carry no action. Every flag, its default, and the reasoning are in [runpane watch](/docs/runpane-cli#runpane-watch) in the CLI reference.

## Ask what you worked on

Pane Chat is also useful after the work is over. It can look across active
panes, recently archived panes, branches, pull requests, and agent logs, then
tell you what actually happened.

Try prompts like:

> What did I finish yesterday?

> What have I been working on this week?

> Summarize active panes and recently archived work.

> Which PRs came out of my Pane sessions today?

Ask for the actual workstream, not just the pane name. A pane can get reused,
so you want the branch, PRs, and agent logs in the answer before you count
something as shipped.

If Pane has archived the worktree, Pane Chat can still use RunPane state, git
branches, GitHub PRs, and local Codex or Claude transcript history when those
are available. If a source is missing, ask it to say that instead of guessing.

## Ask what to work on next

Pane Chat can also help when your queue is too wide. Ask it to look at your
active panes, recently active repos, open pull requests, review requests,
assigned issues, checks, labels, and recent agent work, then rank what deserves
attention.

Try prompts like:

> What should I work on next?

> What PRs are closest to shipping?

> Which issues are real priority and which ones are just backlog noise?

> Look across my last 10 active repos and tell me what I shouldn't start yet.

You get more than a list of repo names. Ask for the reason behind each ranking:
the blocker, the next action, and the evidence Pane Chat used. That makes the
answer useful for deciding whether to review a teammate's PR, finish one of
your own drafts, fix a deploy, or leave a stale backlog wave alone.

Because Pane Chat is initialized with your local skill workflow, it can also
name the right next move: investigate a bug, plan a crisp issue, run PR test
automation, prepare a PR, review a content page, or write a teach-back after
something ships.

## Unattended resilience

Pane Chat has an opt-in unattended mode for overnight and lid-closed runs. When enabled, it:

- Runs `caffeinate` automatically while the lid is open to prevent idle sleep.
- Resumes panes whose agent turn died from a sleep or network interruption as a standard behavior, instead of waiting for you to say "continue."

Pane Chat asks whether to enable this at startup. You can also toggle it mid-session. See [Remote Control → Keep the machine awake](/docs/remote-control#keep-the-machine-awake) for the full sleep/wake story.

## Claude or Codex

You can run Pane Chat with Claude Code or Codex. The toggle in the top-right switches which one you're using.

Both use the same `runpane` commands. The only difference is which agent runs in the terminal.

## How it stays lightweight

Pane Chat doesn't load a giant prompt. It starts with one line:

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

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

```text
<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 caches these skills in the background so Pane Chat can start from local files instead of fetching from GitHub every time.

## How the workflow works

Pane Chat coordinates. It doesn't do the implementation itself.

For real work, the flow looks like this:

1. You tell Pane Chat what you want.
2. Pane Chat talks it through with you and nails down what "done" looks like.
3. It creates a pane and delegates a planning agent to write the plan.
4. After you approve the plan, it delegates an implementation agent.
5. A fresh review agent checks the work.
6. PR prep or test automation runs after review passes.

This keeps your conversation in one place while specialized agents work in clean contexts.

For small, low-risk tasks, Pane Chat can just do it directly. For anything bigger, it'll go through the planning flow unless you tell it to skip that.

## Example flow

1. Add a repository in Pane.
2. Open Pane Chat.
3. Ask it to create a feature pane.
4. It runs `runpane panes create` to set up a worktree pane with your chosen agent.
5. The agent plans the work inside that pane.
6. You approve the plan. Pane Chat kicks off implementation.
7. When the PR's ready, Pane Chat opens fresh review and test tabs.
8. It checks results with `runpane panels output` before telling you it's done.

## Why this matters

Most orchestration tools are tied to one agent or one hosted runtime. Pane Chat works with anything that runs in a terminal because it's just shell commands underneath.

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

Related docs:

- [runpane CLI](/docs/runpane-cli)
- [Remote Control from your phone](/docs/remote-control)
- [Agent Loops](/docs/agent-loops)
- [Panes & Worktrees](/docs/panes-and-worktrees)
- [Running Agents in Parallel](/docs/parallel-agents)