Connected coding agents: hand off one session without exposing your whole workspace
Connected coding agents work best when the handoff is narrow: give the coding tool the one session it needs, for the short time it needs it, then close the grant. That is safer than making a chat system, a local repository, and every installed tool part of one permanent trust zone.
OpenClaw v2026.7.1 adds openclaw attach for this boundary. It launches Claude Code with a temporary MCP configuration bound to a selected Gateway session.
Contents
- Why a coding handoff needs a boundary
- What
openclaw attachactually scopes - A practical handoff workflow
- Keep session access separate from workspace access
- Review the result before the grant disappears
- FAQ
Why a coding handoff needs a boundary
A coding task often starts somewhere that is not a repository: a Telegram thread, an incident room, a customer request, or a long-running agent session. The developer or coding agent needs the relevant history, but it should not inherit every channel, session, credential, and local integration simply because it is helping with one issue.
That distinction matters because MCP servers can expose real tools and data sources to a coding agent. Anthropic’s MCP guidance asks users to trust each server before connecting it, particularly when the server can fetch external content. A broad, permanent connection makes that review hard. A short, session-specific connection makes the intended scope visible.
| Handoff question | Safer default |
|---|---|
| Which conversation can the coding agent read? | One named session, not an account-wide message history |
| How long can it use the connection? | A short TTL with a server-enforced ceiling |
| Which MCP servers are loaded? | The temporary configuration required for this task |
| Which files can it change? | A selected repository or isolated worktree, governed by normal coding-tool permissions |
| How does the team know what happened? | A written checkpoint with the diff, tests, and unresolved questions |
This is why a handoff should be designed as a small contract. The coordinator supplies the task context. The coding agent makes a bounded change. A person or a separate reviewer decides whether that change is ready to merge.
For the broader architecture behind the session boundary, see how OpenClaw works and what OpenClaw is.
What openclaw attach actually scopes
OpenClaw’s Attach CLI gives Claude Code temporary access to one Gateway session through a strict MCP configuration. You can select a session with --session and request a lifetime with --ttl; the Gateway still applies its own upper limit. On a normal launch, OpenClaw revokes the grant when the Claude Code process exits.
The implementation details are worth paying attention to:
- The bearer token goes through environment variables rather than command-line arguments.
- Claude Code starts with
--strict-mcp-configand a temporary--mcp-configpath. - Ambient Claude MCP servers do not join the attached session.
--print-configis for inspection and leaves the grant alive until its TTL expires, so treat the generated configuration as active access rather than a harmless preview.
Those details turn a vague statement such as “let the coding agent see the chat” into something operationally testable. You can identify the session, inspect the temporary configuration, set an expiry, and tell when the normal process exit should end access.
OpenClaw v2026.7.1 introduced this alongside improvements to connected coding workflows, tracked Codex delegation, and native subagent results. The release is a useful reminder that a useful integration is not only about getting more tools into an agent. It is also about making the resulting authority easier to account for.
A practical handoff workflow
Use the smallest handoff that lets the coding agent make progress. The following sequence is a good default for an issue that began in a chat or agent session.
- Name the task and the source session. Record the ticket, request, or incident in the handoff. State which Gateway session contains the relevant context and what the coding agent should not infer from it.
- Prepare a clean code location. Use the intended repository and branch. If unrelated work is already in progress, create a separate Git worktree instead of asking the agent to navigate a dirty checkout. Git documents worktrees as linked working directories that let you work on another branch without disturbing the current tree.
- Attach only the selected session. Start the temporary connection with the shortest practical TTL. Do not use a long-lived grant as a substitute for a handoff note.
- Give the agent an acceptance test. “Fix the bug” is too loose. State the expected behavior, affected paths, commands to run, and whether the task may change dependencies, configuration, or production data.
- Require a checkpoint before side effects. Ask for a proposed plan before migrations, external messages, credential changes, destructive commands, or a pull request. A tool call that can be retried is different from a side effect that may already have happened.
- Close and reconcile. At the end, keep the diff, test output, commit reference, and any uncertainty. Then let the attached process exit or revoke the grant deliberately.
This workflow prevents a slower failure mode: a coding agent that can see the context yet cannot explain which session, tool, branch, or side effect produced the result.
If your task prompt itself needs a durable boundary, the CLI coding agents guide shows why a message file is often better than pasting a growing block of terminal text into an interactive session.
Keep session access separate from workspace access
A session-scoped MCP grant does not replace repository controls. It answers “which conversation and tools can this coding agent use?” You still need to answer “which directory can it edit, what commands can it run, and who approves the resulting change?”
That separation is useful in everyday work:
- A support session may provide the symptom and reproduction steps, while the coding agent gets access only to a disposable branch.
- An incident session may be sensitive, while a reviewer receives only the redacted diagnosis and a focused patch.
- A multi-agent task may let one agent inspect context and another agent implement a change in an isolated worktree.
For the last case, keep the workspace rule explicit. The subagent workspace isolation guide covers why independent working directories reduce accidental overlap between agents. It also makes a later review simpler because the patch has one owner and one branch.
Avoid treating the session transcript as an executable instruction set. A chat can contain pasted logs, untrusted issue comments, links, or requests from people who are not authorized to change code. The handoff should say which facts are evidence, which actions are allowed, and which requests still need human approval.
Review the result before the grant disappears
A short-lived grant helps only if the result survives the handoff. Before the coding session ends, capture a compact completion record:
| Record | Why it matters |
|---|---|
| Source session and task ID | Lets the reviewer trace the request without reopening unrelated conversations |
| Branch, commit, and changed files | Makes the code review concrete |
| Commands run and results | Distinguishes a tested patch from an untested suggestion |
| External side effects | Flags messages sent, tickets changed, downloads created, or migrations attempted |
| Open questions | Prevents an uncertain assumption from becoming a silent production decision |
Do not turn this into paperwork for its own sake. A five-line checkpoint is enough when it lets the next person answer: what changed, why, what was tested, and what remains uncertain.
Connected coding agents are most useful when they preserve that chain of custody. The temporary session grant gets the right context to the right tool. Workspace isolation keeps unrelated work out of the patch. A final checkpoint gives the team something reviewable after the connection closes.
FAQ
What are connected coding agents?
Connected coding agents are coding tools that can receive context or tools from another system, such as an agent Gateway, chat session, issue tracker, or MCP server. The connection should make the scope of that access explicit.
Does openclaw attach give Claude Code permanent access to OpenClaw?
No. OpenClaw documents openclaw attach as a temporary MCP configuration bound to one Gateway session. Normal launches revoke the grant when the Claude Code process exits, while the requested TTL is also subject to a Gateway ceiling.
Why use a strict MCP configuration for a coding handoff?
A strict configuration prevents ambient Claude MCP servers from joining the attached session. That reduces surprise tool access and makes the active integration set easier to inspect.
Should a coding agent work in the main checkout?
Usually not when the checkout contains unrelated work. A dedicated branch or Git worktree gives the agent a clearer change boundary and reduces the chance of mixing two tasks into one diff.
Connected coding agents need a narrow, reviewable handoff
Connected coding agents do not need permanent access to be useful. Bind the coding tool to one session, set a short lifetime, use a clean workspace, and require a completion record. OpenClaw’s openclaw attach feature gives that approach a concrete implementation: a temporary, strict MCP configuration instead of an ambient connection that quietly outlives the task.
Sources: