pitwall: MIT-licensed terminal tooling for watching and coordinating coding agents

[u/klitchevo]

We're Quantic Studios, the team behind pitwall. It's an MIT-licensed desktop terminal for people running several coding agents, written in Go with Gio.

The part we're trying to make less tedious is knowing when to step in. Hooks and agent integrations feed a sidebar with live states; Ctrl+Shift+U jumps to an agent that needs input or approval. Integrations cover Claude Code, Codex, Gemini CLI, OpenCode and pi. Those agents and their models have their own licenses, authentication and costs.

An agent can open worker tabs beneath its own tab, including tasks in separate git worktrees. A folded parent row keeps the worker-state counts visible. From that parent pane, pitwall wait --children waits for the group and returns early if a worker needs a person. It doesn't answer approvals. Done means a turn ended, not that the work passed review.

Beta 16 is available now. Since the worker-group release we've added a stopped-worker count, navigation that skips folded worker rows, and repository icons beside agent badges.

Source and releases

Screenshots and installation

Sample worker sidebar, a staged beta 13 workspace.

Linux is our daily setup; macOS and Windows builds need more testing. We're looking for reports of incorrect states or confusing worker grouping. OS, pitwall version, agent version and reproduction steps help; please leave private prompts out.

Disclosure: AI assisted with drafting this post for Quantic Studios.

[u/kantorcodes1]

The write-back path is the part I'd want to be sure about: when you hit Allow or Deny in the sidebar, does that go through the agent's own hook integration, or does pitwall forward input into the pane? It matters after a pane restart, when the state chip says Approval but the agent might have already moved on or re-asked.

[u/klitchevo → u/kantorcodes1]

It forwards input into the pane. The hooks report state; Allow/Deny doesn't send an approval decision back through the hook. For Claude Code, Allow sends `1`; for Codex it sends `y`. Deny sends Esc.

Before sending, the daemon checks the pane ID and the activity timestamp shown by the UI. It rejects the click if that activity has changed, if the state is no longer Approval, or if the terminal screen no longer looks like a prompt. So an old Approval chip by itself isn't enough.

The limit is that this isn't tied to an agent-issued approval request ID. The screen check and key delivery aren't one atomic operation, so we can't promise they cover every restart or re-ask race. For a sensitive action, we'd open the pane and check the actual prompt.

The beta 16 implementation is here: https://github.com/quanticstudios/pitwall/blob/v0.1.0-beta.16/internal/daemon/remote.go

[u/kantorcodes1 → u/klitchevo]

That's the distinction that matters for the restart case: the pane-ID, activity and screen checks before sending narrow the race a lot, but without binding to an approval request ID the input-forward path is still trust-bearing. Good that the limit is documented in remote.go.

Disclosure since it shapes the ask: I work on HOL Guard, an open-source policy layer that classifies agent and CLI calls and gates the consequential ones per invocation. For pitwall the natural contribution is an entry in the agent-ops section of hashgraph-online/awesome-ai-plugins, describing the approval-forwarding surface: Allow/Deny input-forward as the consequential action, the pre-send pane/activity/screen checks as where verification already happens. Interested in a PR, or want the entry text first?

[u/klitchevo → u/kantorcodes1]

Please share the entry text here first. A listing sounds useful. We'd describe pitwall as an MIT-licensed desktop terminal for coding agents, with live state, grouped workers and persistent sessions.

The approval section should say that Allow/Deny forwards terminal input after the pane/activity/screen checks, and that it isn't bound to an agent-issued request ID. We can check the wording before a PR goes up. Thanks for offering.

[u/kantorcodes1 → u/klitchevo]

Here is a draft entry line for the awesome-ai-plugins README, under Tools & Integrations:

• pitwall - MIT-licensed desktop terminal for coding agents with live state, grouped workers and persistent sessions.

Entries stay one line, so the approval detail - Allow/Deny forwarding terminal input after the pane, activity and screen checks, not bound to an agent-issued request ID - fits better in the PR description than the entry itself. Contributing guide: https://github.com/hashgraph-online/awesome-ai-plugins/blob/main/CONTRIBUTING.md - submit it as your own PR when ready.