claude-code - 💡(How to fix) Fix [FEATURE] Live tunnel from local CLI to claude.ai with artifact rendering surface

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Local Claude Code is where the real power lives — custom agents, skills, MCP servers, full filesystem access, my actual repos, my ~/.claude/ config. Claude.ai is where rich rendering lives — artifacts, interactive visualizations, shareable URLs, version history, in-place iteration UX.

Today there's no way to combine the two. The closest existing primitives are all partial:

• /teleport (cloud → local CLI): one-shot transcript snapshot. After handoff, no live channel — anything not baked into the transcript is gone.
• /remote-control (CLI ↔ mobile app): live bridge of a running CLI session, but only to the iPhone Claude Code app, mirroring the CLI's text UI. No claude.ai/web surface, no artifact rendering. Also one-way in practice today (#42671).
• claude --remote: spins up a fresh cloud session with no local context, no ~/.claude/ config, no local repo state.
• Desktop "Continue in": session handoff, not a live tunnel.
• #56687 ("inverse of /teleport"): asks for CLI → cloud handoff. Different shape — handoff loses the local environment; this request keeps it live.

The gap is specific: a live tunnel from a local CLI session to claude.ai web, with an artifact-rendering surface attached. The canonical workflow it would enable: use local Claude Code with custom agents/skills to do the heavy lifting (read repos, synthesize SME knowledge, build a context tree), then have claude.ai render it as a live, iterable artifact — with the artifact-side conversation able to call back through the bridge for more data, instead of being limited to whatever was statically baked into a transcript.

Proposed Solution

Remote Control already proves the bridge pattern works (mobile app ↔ live CLI session). Extend that pattern along two axes:

1. Add claude.ai/web as a Remote Control surface, not just the mobile app. The web side becomes a rich client attached to the running local CLI session.

2. Add an artifact-rendering layer on top of the bridge. When the local session produces structured output (JSON, datasets, context trees, analysis results), the web side renders it as a native claude.ai artifact — interactive, versioned, shareable — instead of just mirroring the CLI's text stream.

3. Keep the artifact live. When iteration on the artifact needs more data ("regroup by quarter," "drill into this node," "now show me the dependency graph"), the artifact-side conversation calls back through the bridge to the local Claude Code session, which has the full local toolset (agents, skills, MCP servers, filesystem, repos) to fetch or compute it.

The trust boundary already exists — the user explicitly opens Remote Control. This request extends the rendering capability available within that boundary; it doesn't open a new attack surface. The harder problem (prompt injection driving an autonomous agent with local tools) is one local Claude Code already has and presumably has answers for.

Alternative Solutions

1. Have local Claude Code generate the artifact directly (write HTML/React/SVG to disk, open in browser). Works for one-shot static visualizations. Doesn't replace what's being asked for:

• No conversational iteration loop — "make the bars red, try a log scale, group by quarter" requires manually refreshing a tab and there's no version history tied to the messages that produced it.
• Local-machine-only — structurally can't be viewed from a phone or shared without re-hosting it somewhere.
• No shareable URL.
• Hits "works on my machine" rendering drift; the claude.ai artifact runtime is a known, curated environment.

2. /teleport to claude.ai and build the artifact there. Currently the closest workflow. Fails because teleport is a snapshot — anything the artifact needs has to be baked into the transcript before handoff. Iterating on the visualization with fresh local data means going back to the CLI, gathering, re-teleporting. No live channel.

3. Use cloud Claude Code (claude.ai/code cloud sessions) instead of local. Cloud sessions get artifact rendering and multi-device access, but at the cost of the local environment — no access to local repos, personal ~/.claude/ config, custom skills, local MCP servers, or the actual dev machine. The whole point of this request is using the real local environment from anywhere with a richer rendering surface, not spinning up a parallel one.

4. Roll your own with remote MCP + a tunnel (e.g., expose a local MCP server via Cloudflare Tunnel, attach it to claude.ai). Technically possible today and proves the capability isn't blocked by anything fundamental. But it's setup-heavy (operate your own tunnel, auth, server lifecycle), exposes only the MCP-shaped slice of the local environment rather than the full Claude Code session, and doesn't get the conversational coupling between the local agent and the artifact view. A first-party version is the same idea with vastly better ergonomics.

5. DIY remote desktop / SSH into the Mac from a phone. Functionally equivalent in spirit and already possible — which is why this request is reasonable from a security/trust standpoint. But it squeezes artifacts through a terminal, has terrible phone ergonomics, and depends on the user maintaining their own networking. A first-party Remote Control extension is strictly better on every axis.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

I work across multiple repos with custom Claude Code agents (SME-style agents that know each codebase deeply, custom skills, local MCP servers). Local Claude Code is the only place these tools exist.

A common task: I want to build a visualization of how a feature is wired across the codebase — a context tree showing which components/files are involved, their relationships, where the seams are. The local CLI can do all the synthesis work in seconds (the SME agents already know where to look). What it can't do is render the result as an interactive artifact I can explore, share with a teammate via URL, or pull up on my phone in a meeting.

Today's options:

1. Teleport a snapshot to claude.ai — works for the first render, but the moment I want to drill into a node ("expand this subtree, show me the actual call sites") the artifact has no way back to the local agents. I have to go back to the CLI, gather more context, re-teleport, and start over. The conversational iteration loop dies at the handoff.
2. Have local Claude Code write an HTML file — fine for a static one-shot, but I'm tabbing between a terminal and a browser, no version history of the visualization tied to the conversation, and it's stuck on my laptop. Useless from the meeting room with my phone.
3. Use cloud Claude Code — gets me artifacts, but the cloud sandbox doesn't have my SME agents, my local repos, or my MCP servers. The whole reason the visualization is useful is because of the local context.

With a live tunnel + artifact rendering, the loop becomes: ask local CC to map the feature → it synthesizes via SME agents → claude.ai renders the tree as an interactive artifact → I drill into a node → the artifact-side conversation calls back through the bridge for more local data → artifact updates in place → I share the URL with a teammate. Same conversation, same local environment, much better surface.

The pattern generalizes to: any task where local context is the asset and the visualization is the deliverable — codebase architecture maps, dependency graphs, log/trace analysis, SME knowledge synthesis, repo-wide refactor preview, test coverage exploration, etc.

Additional Context

Related issues (this request clusters with these — triage may want to consider them together):

• #56687 — push CLI → cloud (handoff, not tunnel; complementary, different shape)
• #42671 — Remote Control phone → CLI is one-way today
• #28351 — slash commands over Remote Control
• #54247 — extend Remote Control to VSCode extension
• #55842 — unified state across Cowork and Claude chat
• #38545 — Conversation History API for cross-client continuity
• #25791 — Claude Code ↔ Cowork bridge for triggering tasks

These are all variations on "the surfaces aren't connected enough." This request is the artifact-rendering-shaped version of that theme.

Why this is reasonable from a security/trust standpoint:

This is functionally equivalent to running Tailscale + SSH + a remote desktop into my Mac to use Claude Code from a browser — a workflow already possible today with off-the-shelf tooling. A first-party version is a nicer wrapper over a workflow that's already legal and unsurprising. The trust boundary already exists (the user explicitly opens Remote Control); this request extends the rendering capability available within that boundary, not opening a new attack surface.

Possible implementation shapes (non-prescriptive):

• Native: extend Remote Control's session bridge to support claude.ai/web as a client, with an artifact channel layered on top of the existing message stream.
• MCP-based: a polished, first-party "expose this CC session as a remote MCP server" pattern, with claude.ai attaching to it. Less ambitious; gets most of the value with existing primitives.

Either shape would be a meaningful improvement over the current state.