Argus Manages VS Code Worktree Agents

Argus is Petar S. Dimov’s free Visual Studio Code extension for managing AI agent sessions across git worktrees. It deals with the annoying part of running OpenAI Codex and Claude Code, Anthropic’s coding agent, at the same time: too many editor windows, terminals, and dev servers. For the codex cli vs claude code question, the plain answer is that Argus does not pick a winner; it makes either agent easier to supervise when parallel worktrees are the real pain. The useful takeaway is simple: try Argus only if you already use separate worktrees for separate agent tasks.

See the problem Argus is actually solving

Argus is a session manager, not a new coding agent. It sits inside Visual Studio Code, Microsoft’s editor, and tries to bring multiple worktree-bound Claude Code or Codex sessions into one place.

That is why the Show HN post landed. The pain is very familiar: one agent is fixing a flaky test, another is drafting a refactor, and suddenly you are alt-tabbing through three VS Code windows and guessing which terminal owns which dev server.

The author was also refreshingly candid. As of July 2026, Argus is a preview, has rough onboarding, and relies on the native Claude and Codex extensions in ways the author described as hacking around their internals. That makes it interesting, but not something to treat as boring infrastructure yet.

The trap is thinking Argus makes parallel agents safe by itself. It does not. It gives you a cockpit. You still need clean worktrees, scoped instructions, and a verification loop before any code comes back to main.

Keep each agent in its own worktree

The clean version of this workflow starts before Argus opens. Give every agent its own branch and worktree, then let Argus manage those sessions from one VS Code window.

A small repo example might look like this:

git worktree add ../shop-cart-fix -b agent/cart-fix
git worktree add ../shop-copy-polish -b agent/copy-polish

cd ../shop-cart-fix
codex
npm test -- --run cart

This matters because agents are fast at making changes and bad at sharing a messy working directory. Two agents editing the same checkout is not parallelism. It is a race condition with better prose.

For Codex users, the repo instruction file is the quiet hero. Put the durable rules in AGENTS.md, then keep the task prompt small. A scoped file for the cart worktree might say:

# AGENTS.md

- Before editing, read package.json and src/cart/README.md.
- Keep changes inside src/cart unless the task explicitly asks otherwise.
- Run npm test -- --run cart before handing off.
- Do not edit database migrations in this worktree.

That is the difference between “please fix cart bugs” and a Codex workflow you can review. The trap is stuffing task-specific guesses into permanent repo rules. AGENTS.md should hold constraints you want future agents to follow too.

If you are building this into a repeatable practice, the related Codex CLI workflows topic is the better home for the deeper command patterns.

Use Argus to make Codex vs Claude Code less noisy

The “Codex vs Claude Code” comparison gets fuzzy when the real issue is window management. Argus separates those questions. First decide which agent you want for the task, then decide whether one VS Code window should manage several worktrees.

Here is the practical fit table I would use before installing it on a serious repo:

Verdict: Codex wins when your workflow is already built around Codex CLI, AGENTS.md, and repeatable shell verification; Claude Code wins when your daily coding loop already lives in Claude sessions. Argus wins only when you are truly running more than one worktree and the coordination tax is bigger than the preview rough edges.

The trap is using Argus to avoid choosing task boundaries. A session manager can show you three agents. It cannot tell you whether three agents should be touching the same subsystem.

Try the preview on a boring change first

The safest Argus test is deliberately unglamorous. Pick a repo with fast tests, create two tiny worktrees, and assign each agent a change that cannot overlap: one documentation fix, one isolated unit-test cleanup.

Use a handoff receipt before you look at the diff:

## Agent handoff receipt

Worktree: ../shop-cart-fix
Branch: agent/cart-fix
Agent: Codex CLI
Task: Fix cart total rounding test
Files changed: src/cart/total.ts, src/cart/total.test.ts
Verification run: npm test -- --run cart
Known risk: Did not test checkout integration

This is small, but it changes the review mood. You are not replaying a chat transcript to guess what happened. You are checking a branch, a diff, and a command result.

MCP boundaries deserve the same treatment. If an agent has access to GitHub, Slack, a database, or an internal document store through the Model Context Protocol, start read-only unless the task truly needs writes. A good boundary note is plain: “GitHub MCP may read issues and pull requests; it may not create branches, labels, or comments for this task.”

The trap is testing Argus on the exact day you need judgment, speed, and reliability. Preview tools are best evaluated on boring work. Save the heroic refactor for after the cockpit stops surprising you.

A related hardware-flavored experiment, joydex Turns a Flight Throttle Into Codex Controls, shows the same underlying theme: developers are inventing new control surfaces because agent supervision is now part of the job.

Common questions

• Is Argus a replacement for Codex or Claude Code?

  No. Argus is a VS Code extension that manages sessions around the native Codex and Claude Code extensions; it is not a new model or agent runtime. The author’s own positioning is narrow: keep parallel worktree agents in one VS Code window instead of juggling windows, terminals, and dev servers.

• How should I think about codex vs claude code here?

  Think of codex vs claude code as the agent choice, and Argus as the workspace choice. If your repo already uses Codex CLI, AGENTS.md, and shell-based verification, Codex is the natural path. If your work already lives in Claude Code sessions, Argus may still help, but the review loop stays yours.

• Is Argus safe to use on production code?

  Use it cautiously, not blindly. As of July 2026, Argus is described as a preview with rough onboarding and some dependence on native extension internals. Try it on small worktree-isolated changes first, require a handoff receipt, and merge only after local tests and human diff review.

• Do I need git worktrees to get value from Argus?

  Mostly, yes. Argus is aimed at the pain of parallel agent sessions across worktrees, so a single-checkout workflow removes much of the benefit. If you are only running one Codex agent at a time, a normal terminal, clear AGENTS.md, and a tight verification command may be simpler.

• Where does MCP fit in this workflow?

  MCP fits at the permission boundary, not the window-management layer. Argus may help you watch sessions, but MCP controls what external systems an agent can touch. Start with read-only access for issue trackers, docs, and databases, then grant writes only for tasks that explicitly need them.

Best ways to use this research

• Best for: Developers already running multiple AI coding sessions across git worktrees and feeling the window-management pain more than the agent-selection pain.
• Best first artifact: A short AGENTS.md with edit boundaries, one verification command, and a “do not touch” list for risky areas like migrations or auth.
• Best comparison angle: Compare Codex CLI and Claude Code by the task and verification loop first; compare Argus only after you know you need parallel worktree supervision.
• Best safety move: Treat Argus as a preview cockpit. Keep branches isolated, keep MCP permissions narrow, and require a handoff receipt before review.

Further reading

• Argus — source
• OpenAI Developers — AGENTS.md guide
• OpenAI Developers — Codex CLI

Next step

Create two disposable worktrees and run one boring agent task in each. If Argus makes review calmer without hiding risk, it has earned a deeper look.

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.