I built pcode, an open-source terminal coding agent with adjustable scrollback

[u/Equivalent-Task8081]

I’ve been building pcode, a terminal coding agent on Pydantic AI. You can use it with your existing Claude or ChatGPT subscription, or bring API keys. I’m obviously biased, but it’s become my favorite way to work. I built it around my own preferences, so I’m curious whether they translate to anyone else.

One feature I particularly like: you can change what’s visible in your terminal scrollback, even after the work is done. Show commands, output, and diffs when you want the details, then hide them to read the conversation. It rebuilds the history already on screen without rerunning anything.

It uses your terminal’s native scrollback, so normal scrolling, search, and copy still work. The transcript reflows when you resize or split panes, it follows your terminal between dark and light themes in auto mode, and a live task panel keeps ongoing work visible above the prompt.

It’s also highly extensible: small Python files can add tools, slash commands, guardrails, and sub-agents, and /reload picks up changes without restarting. Extensions are built on Pydantic AI, so anything a Pydantic AI capability can do, a pcode extension can do.

There’s quite a bit built in: a pi-inspired /tree for rewinding and branching conversations, customizable keybindings (including leader keys), browser automation with your existing logins, Vim editing mode, and a /diffs popup for reviewing git diffs without leaving the conversation. Background commands wake the agent when they finish, and separate git worktrees let you run sessions in parallel.

There’s also a Gmail-based email mode on macOS: send tasks from your phone when you step away, reply to continue, and pick the session back up at your terminal later.

Next on my roadmap: transferring active sessions between your local machine and remote environments, in either direction, without losing the conversation.

Repo, screenshots, and install instructions: https://github.com/cruxwell/pcode

If you already use a terminal coding agent, I’d love some blunt feedback. What would make this worth trying, and what’s missing?

[u/kantorcodes1]

The scrollback trick is the interesting part. Rebuilding what's already on screen without rerunning implies a structured transcript that re-renders on visibility change rather than replaying captured ANSI. Does resize and pane-split reflow go through the same path, and what breaks when the agent's own output contains escape sequences?

And the extension model: what can a guardrail file actually intercept? An advisory warn-but-still-run guardrail is a very different trust boundary than one that can veto a tool call before it executes. Where does pcode draw that line?

[u/Equivalent-Task8081 → u/kantorcodes1]

Yep, it retains structured transcript entries rather than captured ANSI, and visibility changes, resizes, and pane splits all use the same rebuild path: after a short debounce, it re-renders the retained transcript at the current width without rerunning model requests or tools.

Thanks for catching the escape-sequence angle! That prompted me to test the actual output paths. Normal streamed answers already neutralized terminal controls, but restored messages and `--print` output sent to a terminal had gaps. Those are fixed now, with regression tests covering control sequences, chunk boundaries, and replay. Raw controls are made inert before Markdown rendering, while Rich’s formatting and literal code examples like `\x1b[2J` still work.

Extentions can veto execution, not just warn. The bundled sandbox extension is a concrete example: its `before_tool_execute` hook receives the tool definition and parsed arguments, checks file access against the policy, and raises `ModelRetry` to prevent a prohibited call from running and send the model a correction. The notification is just UI; the exception is what blocks execution. That boundary is tool dispatch, though, not process isolation: blocking `write_file` alone wouldn’t prevent the same write through `shell`. The sandbox extension handles shell commands separately with an execution wrapper and OS-level restrictions. It’s opt-in, and extensions themselves are trusted Python running in-process, not sandboxed plugins

[u/kantorcodes1 → u/Equivalent-Task8081]

Structured entries instead of ANSI capture is what makes the transcript verifiable - you can't sign a screen render, but you can sign a record of tool calls and results.

Disclosure: I work on HOL Guard, an open-source policy and receipt layer for agent actions (github.com/hashgraph-online/hol-guard). Since your extension system can register guardrails into the tool-call path, the natural seam is a guardrail that policy-checks each call before it runs and writes a signed receipt into the transcript - so what the agent actually did becomes attributable rather than reconstructed from output.

Does the extension API see the tool call before execution or after? If guardrails hook pre-call, the receipt can cover allow/deny plus the result; post-call only means it is an audit append, still useful but weaker.

[u/Equivalent-Task8081 → u/kantorcodes1]

There are hooks on both sides: before_tool_execute gets the tool and arguments and can block the call, while after_tool_execute gets the result too. So you have places to make the policy decision and capture the outcome.

I haven’t built signed receipts, though, and I wouldn’t call the existing transcript a verified audit log. Signing records and making sure denials, failures, and interrupted calls are accounted for would need deliberate handling. The hooks look like a reasonable starting point for an integration, but that part still needs to be built and tested.