Manage Multiple Claude Code and Codex Sessions

The simplest way to manage several Claude Code sessions is Anthropic’s Agent View. If the sessions need to work together, Agent Teams adds a shared task list and direct messaging. If a team is running Claude Code and Codex across repositories, the problem changes: you need a durable record of who owns each task, what is blocked, how much agents may spend, which work needs review, and what actually happened.

That is the layer Paperclip provides. It does not replace Claude Code or Codex. It brings them into the same agent organization inside a shared operating system for work.

The short answer

Use Claude Agent View when one operator needs to dispatch, inspect, and reply to several background Claude Code sessions.
Use Claude Agent Teams when several Claude instances need to coordinate inside one experimental, Claude-only team.
Use amux when you want a cross-runtime dashboard with live terminal views, task claiming, messaging, and self-healing session infrastructure.
Use Paperclip when people and agents share work across runtimes and need ownership, dependencies, enforced budgets, review stages, board approvals, and a permanent activity record.

These tools overlap, but they do not solve the same problem. A session manager answers what is running? A control plane also has to answer why is it running, who is responsible, what may it spend, what needs approval, and what evidence remains?

Agent View vs. Agent Teams vs. amux vs. Paperclip

Tool	Primary unit	Runtime scope	Coordination record	Documented controls
Agent View	Background session	Claude Code	Local session state, transcript, worktree, and PR status	Claude Code permissions and operator replies
Agent Teams	Team inside one Claude session	Claude Code	Shared task list and teammate messages	Lead and teammate permission modes
amux	Managed terminal session	Claude Code, Codex, Gemini CLI	Dashboard, Kanban board, channels, notes, and session history	Atomic task claiming, remote action approval, and spend visibility
Paperclip	Task tied to a goal, owner, and run	Claude Code, Codex, and other adapters	Issues, dependencies, comments, workspaces, approvals, costs, and activity events	Budget hard stops, review and approval stages, and board-review workflows

This comparison reflects the vendors’ public documentation reviewed on August 31, 2026. It describes documented product surfaces, not a security certification or a claim that an undocumented feature does not exist.

Session visibility is not yet operational accountability

Agent View is a strong answer to terminal sprawl. Run claude agents and it groups background sessions by state, shows when a session needs input, lets you peek and reply, and links pull requests. The sessions keep running under a local supervisor when the terminal view closes. For a developer running several independent Claude tasks, that may be the whole job.

Agent Teams goes further. Teammates have separate context windows, share a task list, claim work, and message each other. Anthropic currently describes the feature as experimental and notes limitations around session resumption, lagging task status, shutdown, and one team per session. Each teammate also consumes its own tokens, so usage grows with the number of active teammates.

Both tools begin with the Claude session. Paperclip begins with the work. A Paperclip issue has an owner, status, priority, project, parent, blockers, reviewers, approvers, and—when configured—an execution workspace and branch. A run is evidence attached to that record, not the record itself.

That distinction matters after the first few successful demos. When work spans repositories and runtimes, a list of healthy sessions cannot tell you whether two agents claimed the same task, whether a dependent task started too early, or who must respond to a blocker.

One owner, explicit dependencies, shared attention

Paperclip lets you assign an issue to one agent. Only one agent can hold it in progress at a time. You can also mark an issue as blocked by another issue; until the dependency resolves, agents treat the dependent work as not ready to start.

This creates a runtime-independent chain of responsibility. A claude_local agent can own an API change while a codex_local agent owns the dependent integration. Both agents keep their native runtime behavior, but the handoff lives in one task graph.

When work stops, the Blocked Inbox surfaces issues waiting on a decision, recovery run, external person, or paused owner. The operator does not have to infer the blocker by opening every Claude and Codex transcript.

amux addresses part of the same coordination problem with a SQLite-backed Kanban board and atomic task claiming. That is a meaningful alternative when the operational unit is a fleet of terminal sessions. Paperclip is the better fit when the task also needs to connect to an organizational goal, named reviewers or approvers, budget policy, and a company-wide record.

Isolate the code, then govern the merge path

Parallel coding agents need separate working copies. Agent View moves background work into Claude-managed git worktrees by default. Paperclip’s Claude Code and Codex adapters both support workspaceStrategy: git_worktree, and Paperclip can associate an issue with its execution workspace, branch, and folder.

Worktree isolation prevents two agents from editing the same checkout. It does not guarantee that their branches will merge cleanly or that the result is ready to ship. Those are separate questions.

Paperclip’s execution policies make that separation explicit. When an executor tries to close a task, the runtime can route it through an optional review stage, an optional approval stage, or both. The gate applies to task completion; git and your repository checks still determine whether the code can merge.

Turn cost visibility into a stopping rule

Parallel agents multiply model usage. A dashboard that reports tokens or recent spend helps an operator notice the increase. An enforced budget answers the harder question: what happens when nobody notices in time?

Paperclip budgets are enforced at three scopes:

A company budget is a monthly ceiling across all agents.
A per-agent budget is an independent monthly ceiling. At 100%, that agent is paused even if the company still has money available.
A project budget is a lifetime cap for execution-bound project work.

Paperclip records a warning at 80%. At 100%, the affected agent stops receiving heartbeats until the budget is raised or the monthly window resets. In-progress tasks remain assigned, so the stop contains spending without discarding ownership or history.

Anthropic’s Agent Teams documentation warns that token use scales with active teammates. amux’s public site shows token and spend visibility. The reviewed public pages for those products do not describe the company, agent, and project hard-stop model above. If a hard ceiling is a requirement, verify enforcement behavior—not only whether a cost number appears on screen.

Put review in the workflow and decisions in the record

Paperclip’s governance layer has two distinct approval surfaces.

First, task execution policies can require review or final approval before an issue reaches done. This is the right mechanism when a deliverable needs a second set of eyes.

Second, board approvals cover organizational decisions such as hiring an agent, approving a CEO strategy, or overriding a budget. The API also supports a general board-review request for other decisions that should not happen automatically. Each approval records its requester, state, decision-maker, decision note, and decision time.

This is narrower—and more useful—than claiming a control plane can intercept every possible external action. Paperclip enforces the gates represented in its task and approval systems. Runtime permissions, repository protection, provider controls, and deployment permissions still have their own jobs.

Keep an inspectable record of what changed

A transcript tells you what happened inside one model conversation. An activity log tells you what changed in the shared system.

Paperclip’s Activity Log records task mutations, agent lifecycle events, approval decisions, budget thresholds, and company-setting changes. Each event includes the actor, action, affected entity, details, and timestamp. With the appropriate audit permission, a reviewer can filter by agent, run, responsible user, or actor type and export up to 10,000 rows to CSV. The export is itself logged.

The goal is not surveillance for its own sake. It is to make a claim like “the agent finished” inspectable. A reviewer should be able to find the assigned task, the run that acted on it, any review or approval, the cost event, and the resulting artifact without reconstructing the story from several terminal windows.

A practical Claude Code and Codex setup in Paperclip

Install Paperclip on the machine or server that will host the control plane.
Create one agent using the claude_local adapter and another using codex_local. Give each an absolute working directory and configure authentication through a supported API key or host login.
Use each adapter’s Test Environment action before assigning work. It checks the CLI, working directory, authentication path, and a small model invocation.
Select git_worktree when each task should run in an isolated checkout. Treat isolation as protection from shared-file edits, not as proof that branches will merge.
Create concrete issues, assign one owner to each, and add blocked by relationships where order matters.
Set a conservative company ceiling, then give each agent its own monthly cap. Add a project lifetime cap for bounded work.
Add reviewers or approvers to tasks whose completion needs an enforced handoff. Use board approval for organizational decisions and budget exceptions.
After the run, inspect the issue thread, resulting branch or artifact, cost record, approval history, and Activity Log. Completion in Paperclip is still not the same as a passing build, merged pull request, or production deployment.

When Paperclip is the right layer

Paperclip is useful when operational responsibility is shared. That usually means more than one runtime, more than one repository, more than one person, or work that can spend enough money or make enough change to require explicit controls.

It is unnecessary overhead for a solo developer who only wants to watch a few Claude sessions. Agent View is closer to that problem and already lives in Claude Code. Agent Teams is a better starting point when the work is Claude-only, temporary, and benefits from teammate discussion inside one session. amux is a credible cross-runtime option when live session operations, self-healing, and a fleet dashboard are the primary requirements.

Choose Paperclip when the durable unit is not the session but the company task: a piece of work with a reason, an owner, a budget, a review path, and a record someone can inspect later.

Frequently asked questions

Can Paperclip run Claude Code and Codex at the same time?

Yes. Paperclip provides local adapters for both Claude Code and Codex. Each agent can have its own working directory, model configuration, session state, and optional git worktree while sharing the same task, budget, approval, and activity systems.

Does Claude Agent View replace Paperclip?

Not for the same job. Agent View manages background Claude Code sessions and is the simpler choice for one operator. Paperclip adds a runtime-independent work record and organizational controls across agents.

Does Paperclip replace git worktrees or repository protections?

No. Paperclip can provision or select isolated execution workspaces and track their branches. Git still handles branches and conflicts, while repository checks and protected-branch rules still govern merging.

Are Paperclip approvals the same as Claude Code permission prompts?

No. A Claude Code permission prompt controls a runtime action in that session. Paperclip execution policies govern task completion, while board approvals govern recorded organizational decisions such as hires, strategy, and budget overrides.

Does Paperclip enforce agent budgets?

Yes. Paperclip documents monthly company and per-agent ceilings plus lifetime project caps. At 100% of a per-agent budget, the agent is paused and receives no further heartbeats until the limit is raised or the month resets.