Claude Code multi-agent workflows: attach a live OpenClaw session safely
Claude Code multi-agent workflows work best when each agent has a clear job and a narrow way to exchange context. openclaw attach provides one such boundary: it starts Claude Code with a temporary, strict MCP configuration tied to one OpenClaw Gateway session. That lets a coding agent contribute to a live session without inheriting every MCP server or turning a one-off handoff into permanent access.
This is a useful fit when a conversation has already established the problem, decisions, and constraints, but the next step belongs in a coding workspace. Instead of pasting a summary into another terminal and hoping nothing important was omitted, attach the selected session and keep the handoff scoped.
OpenClaw added openclaw attach as part of v2026.7.1, alongside broader connected coding-agent work. The feature is small. The operational boundary is the interesting part.
What openclaw attach actually does
According to the Attach CLI reference, openclaw attach launches Claude Code with a strict, temporary MCP configuration bound to a single Gateway session. The default target is the main session; --session selects another session key, and --ttl requests a positive time-to-live in milliseconds.
The command deliberately avoids a few common footguns:
- The bearer token travels through environment variables rather than the command line.
- Claude Code is launched with
--strict-mcp-config, so ambient Claude MCP servers do not silently join the attached session. - A normal launch revokes the grant when the Claude Code process exits.
--print-configis available when an operator needs to inspect the temporary configuration and launch details without spawning Claude Code.
That is not a general-purpose bridge between every agent you have running. It is a per-session grant. Treating it that way makes the workflow easier to reason about and easier to revoke.
Where Claude Code multi-agent workflows usually break
Most multi-agent failures are not failures of model quality. They happen at the seam between agents: an incomplete handoff, a shared workspace, a stale summary, or credentials that remain available after the task ends.
Claude Code’s own Agent Teams documentation makes a useful distinction. Subagents are good for focused work that reports back to the caller. Agent teams are for work that needs independent contexts, direct communication, and a shared task list. Agent teams also cost more and add coordination overhead, so they are not a default for every task.
An attached OpenClaw session solves a different problem. It gives one Claude Code process a bounded connection to the particular live session whose context it needs. The three patterns can coexist, but they should not be confused.
| Pattern | Best use | Main boundary |
|---|---|---|
| Claude Code subagent | Focused research, review, or verification | Results return to the parent session |
| Claude Code agent team | Parallel work that requires direct coordination | Independent contexts plus a shared task list |
| OpenClaw attach | Bringing a selected live Gateway session into a coding task | Temporary strict MCP configuration for one session |
If you only need a second opinion on a file, a subagent is probably enough. If several coding agents need to negotiate ownership of separate modules, use an agent team or another explicit coordination system. If the coding task needs the state of a live OpenClaw session, attach that session instead of broadening access to everything.
A practical handoff pattern
A clean handoff has four stages. The point is not to automate each stage. The point is to make ownership visible.
- Choose the session. Identify the Gateway session that contains the relevant decisions and current task state. Do not attach a broad default session out of habit if a narrower session exists.
- Set the expiry. Use a TTL appropriate for the work. A short troubleshooting pass and a long implementation session should not receive the same window by default.
- Run the coding task. Let Claude Code operate in its normal project context while using the attached session only for the context it needs.
- Close the loop. Confirm the process exits or explicitly end the task. A normal
openclaw attachlaunch revokes the grant on process exit, so the access path does not become a quiet permanent integration.
For recurring work, write the task brief down before opening the attached session. The CLI coding agents guide explains why a reviewable message file is safer than a long shell-pasted prompt. The same principle applies here: an attached session can provide context, but the coding task should still have a clear scope, verification command, and file boundary.
Keep session context and workspace access separate
Session context is not permission to write everywhere. A live conversation can tell an agent why a change is needed; it should not erase the workspace controls that prevent unrelated edits.
This is where the workflow connects to subagent workspace isolation. Parallel agents need separate working directories and scoped task context when they can modify files concurrently. Attaching a session does not replace that isolation. It only gives a coding agent a controlled way to consult the live state behind the request.
A sensible setup keeps these boundaries separate:
| Concern | Question to answer | Practical control |
|---|---|---|
| Session context | Which conversation does this coding task need? | Bind openclaw attach to the selected Gateway session |
| MCP exposure | Which tool servers can this Claude Code process use? | Strict temporary MCP configuration |
| Workspace writes | Which files can the agent change? | Project scope, worktrees, and reviewable task constraints |
| Duration | How long should the handoff remain valid? | TTL and process-exit revocation |
| Coordination | Who owns related tasks? | An explicit task list, Workboard, or the agent team’s own coordination model |
That separation sounds fussy until a task goes wrong. Then it is the difference between investigating one scoped session and discovering that an old agent process retained more access than anyone intended.
When not to use an attached session
Do not reach for openclaw attach just because two tools have agent in the name.
Skip it when the coding work is self-contained and the brief already includes all relevant context. Skip it when the task is a simple parallel review that Claude Code subagents can handle internally. Avoid it when several agents need to edit the same files without an ownership plan; a session bridge does not prevent merge conflicts.
It is also worth resisting the urge to make every agent workflow autonomous. Claude Code’s documentation notes that agent teams are experimental and have limits around resumption, coordination, and shutdown. That is a reason to start with independent tasks and explicit handoffs, not a reason to wire every available agent into one long-lived mesh.
Why strict temporary access is the useful default
The important design choice in openclaw attach is not that it can launch Claude Code. Plenty of scripts can launch a CLI. It is that the launch is tied to a session, uses a strict temporary configuration, passes the bearer token outside argv, and revokes the normal grant when the child process exits.
Those defaults give operators something concrete to inspect. The session is named. The time window is bounded. The MCP configuration is not ambient. The coding process has a defined end.
That makes attached sessions a good complement to how OpenClaw works: use the Gateway for durable session and delivery context, then give a coding agent only the temporary connection it needs to finish the next piece of work.
FAQ
Is openclaw attach the same as a Claude Code agent team?
No. Claude Code agent teams coordinate multiple Claude Code instances with independent context windows and a shared task list. openclaw attach launches one Claude Code process with temporary, strict MCP access to a selected OpenClaw Gateway session.
Does an attached Claude Code process inherit all of my MCP servers?
The Attach CLI reference says OpenClaw launches Claude Code with --strict-mcp-config and a temporary configuration, specifically to keep ambient Claude MCP servers from joining the attached session.
How long does the attached-session grant last?
You can request a positive TTL with --ttl; the Gateway applies its own ceiling. For a normal launch, OpenClaw revokes the grant when the Claude Code process exits.
Should I attach a session for every coding task?
No. Use it when the coding task genuinely needs the state of a live OpenClaw session. For a self-contained task, a written brief or a Claude Code subagent is usually simpler and cheaper.