If you already run OpenClaw as your long-lived Gateway and you sometimes jump into Claude Code for a tighter coding loop, the awkward part has usually been the handoff. You had a live Gateway session with the right tools, the right auth, the right context, and then you still had to recreate that setup manually inside Claude Code.

That is the gap openclaw attach closes in OpenClaw v2026.7.1-beta.1. The new command launches Claude Code against an existing Gateway session with a temporary, scoped MCP grant, so you can resume the session you already trust instead of rebuilding everything from scratch.

For developers using OpenClaw as the durable layer and Claude Code as the interactive editing surface, this is one of the more useful workflow upgrades in the current beta.

In this guide

What OpenClaw Attach actually does

The short version from the new Attach CLI docs is simple: openclaw attach launches Claude Code with a strict temporary MCP config bound to one Gateway session.

That wording matters.

This is not a generic “connect Claude Code to everything on my machine” shortcut. It is a session-scoped bridge. OpenClaw mints a temporary attach grant for a specific Gateway session, writes the returned MCP config to a temporary .mcp.json, launches Claude Code with --strict-mcp-config --mcp-config, and revokes the grant when the Claude Code process exits.

The release PR explains why this is better than the old manual path. Before this command, a user had to hand-mint a grant, hand-write the MCP config, pass the right auth headers, and remember to clean up afterward. openclaw attach turns that into one command while keeping the boundary temporary and revocable.

The main flags are small but useful:

openclaw attach
openclaw attach --session agent:main:telegram:123
openclaw attach --ttl 600000
openclaw attach --print-config

According to the docs:

  • --session <key> binds the grant to a specific Gateway session
  • --ttl <ms> requests how long the grant should live
  • --bin <path> lets you point at a specific Claude Code binary
  • --print-config writes the temporary config and prints the launch command so you can inspect it before launching

Why this matters for coding workflows

There is a practical difference between “start a coding agent” and “resume the coding session that already has the right state.”

If you use OpenClaw as the durable control plane, you already have a lot sitting behind that session:

  • the channel or surface that originated the work
  • the session transcript and run history
  • the model and provider setup already selected in the Gateway
  • the same tool permissions and approval rules attached to that session
  • the same auth and connected services the Gateway already knows how to use

That is why the release notes describe attach as an external harness attachment feature that makes Codex-style workflows easier to resume and inspect. The important word is resume.

A few real cases:

1. You started the task in chat, but the work became code-heavy

Maybe the task began in Telegram, Slack, or the Control UI. The agent already has the goal, the transcript, and the earlier tool results. When the task turns into a longer coding pass, openclaw attach lets you move into Claude Code without losing that continuity.

2. You want tighter local iteration without changing the session identity

A lot of developers prefer Claude Code once they are in the edit-run-fix loop. That does not mean they want a brand new session with different permissions and a different audit trail. Attach keeps the session boundary intact.

3. You need to inspect a stuck or interrupted run

Sometimes the job is not to start over. It is to understand what the existing session can still see, what tool state it still has, and where the failure happened. A session-scoped attach flow is cleaner than reconstructing the context from memory.

If you want the broader mental model for how OpenClaw handles sessions, channels, and long-lived agents, the best internal primer is How OpenClaw works. If you are still tuning your development setup, our multi-agent setup guide and Windows/WSL setup guide are the more useful starting points.

How to use OpenClaw Attach

The easiest way to think about it is: make sure your Gateway session already exists, then attach Claude Code to that session instead of opening a disconnected local coding run.

Step 1: get the Gateway running the way you want

OpenClaw’s setup guide now explicitly describes the “bleeding edge” workflow where you run the Gateway yourself and let other surfaces attach to it. That is the natural home for openclaw attach.

If you are running from source, the relevant pattern looks like this:

pnpm install
pnpm openclaw setup
pnpm gateway:watch

That gives you a live Gateway with your real tools, sessions, and auth available through the normal OpenClaw control plane.

Step 2: choose the session you actually want to resume

If you do not pass --session, OpenClaw defaults to the main session. That is fine when your work is simple. It is a bad habit once you use multiple agents, multiple channels, or sender-scoped sessions.

In those cases, be explicit:

openclaw attach --session agent:main:telegram:123

The point is not just correctness. It is keeping the coding run attached to the exact conversation and permission boundary that produced the work in the first place.

Step 3: inspect the config if you want a slower, safer handoff

If you are testing the feature or you want to verify what Claude Code will receive, use --print-config first:

openclaw attach --session agent:main:telegram:123 --print-config

This writes the temporary MCP config, prints the launch command and environment details, and leaves the grant alive until the TTL expires. That is the best option when you want to inspect the handoff instead of launching immediately.

Step 4: keep TTL short unless you have a reason not to

The docs note that --ttl only requests the lifetime and the Gateway applies its own ceiling. That is the right shape. In practice, short-lived grants are what you want for most coding sessions:

openclaw attach --session agent:main:telegram:123 --ttl 600000

Ten minutes is enough for many handoffs. If the work is longer, reattach deliberately instead of leaving grants hanging around all afternoon.

What the security boundary looks like

This is the part I would not skip.

openclaw attach is useful because it is not a permanent credential export. The attach docs and PR both emphasize the same guardrails:

  • the grant is tied to one Gateway session
  • Claude Code is launched with --strict-mcp-config
  • the bearer token is passed through environment variables, not command-line args
  • the temporary grant is revoked when the Claude Code process exits
  • --print-config is the exception path, and even there the grant is TTL-bounded

That is a noticeably better boundary than handing a coding tool a broad, durable token and hoping you remember what it can still reach three days later.

This also fits OpenClaw’s general pattern of scoped surfaces and session-aware control. If that is the part you care about most, the adjacent reads are the Codex approvals write-up and our security overview.

When to use attach vs. starting fresh

Use openclaw attach when the existing session is the asset.

That usually means:

  • the task started elsewhere and now needs a code-focused surface
  • the session already has the right context and auth
  • you want the same session transcript and policy boundary
  • you are resuming or inspecting work rather than opening a brand new job

Start fresh when the old session is baggage.

That usually means:

  • the original thread mixed unrelated goals
  • you want a different agent or model policy entirely
  • the existing session permissions are broader than this task needs
  • you want a clean transcript for review or sharing

This is the same tradeoff people already make with active-run steering: sometimes continuity is the win, and sometimes the clean reset is the win. Attach is the continuity tool.

The bigger takeaway from v2026.7.1-beta.1

The flashy item in the beta is probably GPT-5.6 support, and that will pull more search volume. But for actual daily workflows, openclaw attach may turn out to be the stickier feature.

A lot of self-hosted AI tooling is good at starting new sessions and bad at preserving the one you already shaped. Attach fixes that in a way developers immediately understand: keep the Gateway as the durable layer, then drop Claude Code onto the exact session that already knows what is going on.

That is a better workflow than recreating the environment by hand, and it is a safer workflow than passing around a broad permanent token just to save thirty seconds.

FAQ

Does OpenClaw Attach work only with Claude Code?

Right now, the official docs describe openclaw attach as launching Claude Code with a strict temporary MCP config. The release notes call the feature “external harness attachment,” but the public CLI docs are specifically written around Claude Code today.

What is the main SEO keyword to remember here?

If you are searching for this feature later, the exact product-intent phrase is OpenClaw Attach. The long-tail intent behind it is usually some version of “resume Claude Code on an existing Gateway session.”

Is --print-config safer than launching directly?

It is safer for inspection, not safer by default. It leaves the temporary config in place until the TTL expires, which is useful for debugging and verification. For normal use, the default launch path is cleaner because the grant is revoked when Claude Code exits.

Should I always pass --session?

If you run more than one meaningful session, yes. The default main session is convenient, but explicit session targeting is what prevents accidental cross-thread handoffs.

Is this available in the stable changelog yet?

Not at the time of this run. The feature is highlighted in v2026.7.1-beta.1, while the public web changelog is still anchored to the latest stable release line.

Sources: