Juggler Turns Coding Agents Into a Workbench

Juggler is an open-source GUI coding agent from Julian Storer, the creator of JUCE, Tracktion, and Cmajor. It deals with a very specific pain: coding agents can change a repo faster than many developers can inspect what just happened. The useful answer here is not “use a better model”; it is “make the agent’s work visible enough to review.” A better question than “what is the best ai tool for code review” is whether the tool leaves a trail you can actually trust.

Juggler is a visual workbench for agentic coding sessions. Instead of treating the session as a terminal transcript, it represents the work as a tree: tool calls, context items, approvals, thread branches, and nested sub-threads are meant to be browsed directly.

As of July 2026, the juggler-ai/juggler repository is mainly JavaScript, AGPL-3.0 licensed, and had 263 GitHub stars in the source signal. The project is young, but the design target is clear: less doom-scroll, more inspection.

See the agent’s work before you judge the patch

The most interesting thing about Juggler is not that it has a GUI. It is that the GUI is aimed at the part of agentic coding that usually gets hand-waved: how you reconstruct the agent’s reasoning after it has touched files.

A CLI coding agent can be great while you are driving it. The trouble starts when the terminal fills with chat, file reads, tool calls, retries, half-finished plans, and “fixed it” messages. By the time a pull request exists, the reviewer often sees only the diff and maybe a summarized rationale.

Juggler’s answer is to make the session navigable. Its README describes a Finder-style Miller column view for tool calls, item properties, nested sub-threads, and raw context. That matters because review is easier when you can ask small questions: which files did the agent read, what did it approve, where did the branch split, and what context was edited?

The trap is assuming “visual” means “safer.” A GUI can make dangerous work look tidy. The safety comes from whether the work is inspectable, whether approvals are explicit, and whether the session trail survives long enough to become part of review.

For Codex users, this is the familiar gap between a good coding run and a reviewable handoff. OpenAI’s Codex can help produce and test a change, but your repo still needs durable rules in AGENTS.md, a verification loop, and a receipt that tells the reviewer what changed and how it was checked.

Understand why Hacker News cared

The Hacker News reaction was not just “nice UI.” Developers noticed a real split in the coding-agent world.

Some people are tired of GUI-heavy editors and prefer terminal-first tools. Others like model-independent agents but hate being trapped in a long CLI scrollback. Juggler sits right on that fault line: it is open source and extensible, but it makes a strong bet that serious agent work deserves a proper graphical workbench.

That bet is more interesting because of who made it. Storer is a long-time C++ developer known for developer tools in audio software. His own framing was basically: I loved what the models could do, but hated the CLI experience enough to build my own take.

The project’s plugin story also drew attention. Juggler’s README says context items, slash commands, loop strategies, and UIs are JavaScript extensions that can be inspected, forked, or replaced. That is the right instinct for developers who do not want a sealed “code review ai” box deciding what matters.

The honest objection is interoperability. One commenter wanted Agent Client Protocol support because rewriting existing plugins would be a blocker. That is a fair concern. In an ecosystem where Codex, Anysphere’s AI code editor, OpenAI Codex, and other agents already have their own surfaces, a new workbench has to be good enough to justify another integration path.

There was also the predictable Electron-adjacent debate. Juggler advertises itself as “No Electron,” and some developers questioned whether the chosen desktop stack is really the selling point. I would not over-index on that. The more durable question is whether the session model helps you review agent work better than a chat log.

Try it when review context keeps disappearing

Juggler is worth trying if your current agent workflow loses context between “the model did something” and “a human reviewed it.” That is the practical seam. Not model routing. Not another benchmark. The seam is whether the agent’s work can be replayed as engineering evidence.

A good small test is a low-risk repo task: update a package, adjust one failing test, or refactor a small helper. Let the agent work. Then inspect the session like a reviewer, not like the person who prompted it.

Ask three questions.

Did the agent read the files a human would have read? Did it make a change that matches the issue, not just the error message? Did it leave enough evidence for someone else to approve the patch without trusting the chat summary?

This is where the ai code review angle becomes real. Many ai code review tools focus on finding comments after a diff exists. Juggler is more interesting as a pre-review lens: it helps you inspect the agent session that produced the diff.

It is overkill for tiny one-shot edits. If you are fixing a typo, a terminal agent plus normal Git review is fine. It may also be a poor fit if your workflow depends on a mature plugin ecosystem that Juggler does not yet support.

For a broader map of this problem space, the related training topic on agentic coding governance is useful. For the narrower Juggler story, we also covered why Juggler Makes Coding Agents Visible.

Keep one review receipt beside the GUI

The practical takeaway is simple: do not let the GUI be the only receipt. If Juggler makes the session visible, use that visibility to produce a small review handoff that can live in the PR.

Here is a lightweight pattern for a Codex-style repo. Put durable review expectations in AGENTS.md, then ask the agent to include a short receipt before it stops.

# AGENTS.md

## Agent review receipt

For every non-trivial change, include a short handoff with:

- Files changed and why each file changed.
- Context used: issue, docs, tests, logs, or MCP resources.
- Tool actions worth reviewing: file writes, generated code, migrations, dependency changes.
- Verification run: exact commands or checks performed, with pass/fail status.
- Known risks: behavior not covered by tests, uncertain assumptions, follow-up work.

## MCP boundary

Use read-only MCP access for GitHub issues, docs, and tickets unless the task explicitly asks for writes.
Do not create branches, comments, tickets, or releases through MCP without human approval.

That instruction works whether the agent session happened in Juggler, Codex, or another coding agent. The point is to separate the beautiful workspace from the durable artifact. Reviewers should not need to replay the whole session to understand the patch.

The trap is asking the model for a receipt after it has already lost track of what mattered. Ask for the receipt as part of the task. Better still, make it a repo rule so the agent expects to produce it every time.

Try Juggler safely

Use this as a small experiment, not a grand platform decision.

A safe first run should touch a disposable branch, use a task with existing tests, and end with a human-owned review. Do not give any new agent write access to production systems, private package registries, or issue trackers until you know exactly how approvals and MCP boundaries behave.

For Codex users, keep the verification loop boring. Run the repo’s normal test command. Ask the agent to explain failures without patching blindly. Then compare the final diff, the Juggler session tree, and the review receipt. If those three agree, you have something worth repeating.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Codex artifact first: an AGENTS.md instruction, a Codex CLI verification loop, an MCP boundary note, or a skills handoff.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about ai code review?

  Start by writing down one visible team rule for Codex, not a loose preference. That is the practical core of ai code review. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Codex artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a AGENTS.md instruction, MCP note, or verification checklist. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Codex teams deciding which AGENTS.md instruction, CLI workflow, MCP boundary, or verification loop to standardize next around “Juggler Turns Coding Agents Into a Workbench.”
• Best first artifact: turn the named fix into an AGENTS.md rule, verification checklist, MCP note, or review receipt before the next automated run.
• Best comparison angle: compare the workflow against the current Codex CLI review loop, shell boundary, and evidence trail; keep the path that leaves the shortest auditable trail.

Further reading

• juggler — source
• Codex — Agent
• OpenAI Developers — Codex quickstart
• developers.google.com: fundamentals creating helpful content

Where to go next

Start from the related training topic and make the first exercise prove scope, verification, and ownership in the PR body.