[BUG] Artifact tool absent in sessions spawned by `claude remote-control` (server mode); `claude --remote-control` works on the same machine and account

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

The Artifact tool is absent from every session spawned by claude remote-control (equivalently claude rc), while claude --remote-control on the same machine, account, and version has it. Since claude remote-control is the documented way to reach a local machine from the Claude mobile app, the practical effect is that a session started from the phone silently cannot publish artifacts, and Claude falls back to writing a local HTML file.

The two commands are different mechanisms:

• claude remote-control / claude rc is a hidden subcommand that runs a persistent server spawning sessions on demand. Sessions it creates get entrypoint: sdk-cli.
• claude --remote-control [name] is a documented flag that starts one interactive session with Remote Control enabled. That session keeps entrypoint: cli.

Only the second has the Artifact tool.

What Should Happen?

A session reached through the Claude mobile app should have the same Artifact availability as any other signed-in interactive session on that machine, or the limitation should be stated somewhere a user would find it.

Error Messages/Logs

# Environment inside a session spawned by `claude remote-control`:
CLAUDE_CODE_ENTRYPOINT=sdk-cli
CLAUDE_CODE_ENVIRONMENT_KIND=bridge

# There is no error. The tool is simply absent from the registry:
ToolSearch "select:Artifact"  ->  No matching deferred tools found

# Meanwhile the built-in agent definitions still reference it by name,
# so the client ships the concept but never receives the grant:
#   Explore, Plan: "All tools except Agent, Artifact, ExitPlanMode, Edit, Write, NotebookEdit"

Steps to Reproduce

On a Mac mini, Max plan, signed in with /login:

1. Run claude remote-control in a terminal.
2. Connect from the Claude iOS app (also reproduced from the desktop app on Windows): tap Code, then Remote, then the plus button, then select the remote computer running the server.
3. Ask for an artifact.

Result: the Artifact tool is not in the session's tool registry. A deferred-tool lookup for select:Artifact returns no match, and keyword searches return nothing artifact-related. Claude writes a local HTML file instead.

Now do the same on the same machine with the flag instead:

1. Run claude --remote-control in a terminal.
2. On the iOS app, tap Code, then Remote, then select the already-started remote control session from the list.
3. Ask for an artifact.

It publishes normally.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

N/A

Claude Code Version

2.1.239 (Claude Code), also reproduced on 2.1.237

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other. herdr terminal multiplexer, reached over SSH from Windows Terminal, and from the Claude iOS and desktop apps via Remote Control.

Additional Information

Evidence from local transcripts

Every record in ~/.claude/projects/**/*.jsonl carries an entrypoint field, and Artifact tool calls correlate with it perfectly:

| entrypoint | records | Artifact tool_use calls |
|---|---|---|
| cli | 26,868 | 296 |
| sdk-cli | 9,232 | 0 |

Across 50 sessions that were sdk-cli for their entire life, there are zero Artifact calls.

One session is mixed and makes the boundary unambiguous. It began under claude rc, where a request for an artifact hit this same blocker, which is why I switched to a normal CLI session, where the same request published fine:

| window | entrypoint | prompts | Artifact calls |
|---|---|---|---|
| 17:23 to 18:45 | sdk-cli | 12, all promptSource: sdk | 0 |
| 18:50 to 02:19 | cli | typed and queued | 123, first at 18:52 |

The entrypoint flips at 18:50:42 and the first Artifact call lands two minutes later. Nothing published during the bridge window.

What I ruled out

• disableArtifact is not set in any settings file.
• CLAUDE_CODE_DISABLE_ARTIFACT and CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC are unset.
• No /Library/Application Support/ClaudeCode/managed-settings.json exists.
• Artifact is in permissions.allow, not permissions.deny.
• Max plan, Anthropic API, signed in via /login, no ANTHROPIC_API_KEY set.
• enableArtifact: true in user settings, then a full restart of the claude rc server, does not help. This is the only documented on-switch and it does not reach this case.
• claude rc --help exposes no tool-related option: only --name, --session-id, --permission-mode, --spawn, --capacity, --create-session-in-dir, --continue, --debug-file, --verbose.

Relation to the docs

The Availability table at https://code.claude.com/docs/en/artifacts#availability says artifacts are "Off by default in Agent SDK, GitHub Action, and MCP-server contexts". Sessions spawned by claude remote-control come up with entrypoint: sdk-cli and CLAUDE_CODE_ENVIRONMENT_KIND=bridge, so that row is presumably the mechanism.

The problem is that nothing connects the two for a user. claude remote-control is presented as the way to drive your machine from the phone, not as an Agent SDK context, and the Remote Control docs do not mention any capability difference between the subcommand and the --remote-control flag. From the user's side it just looks like artifacts randomly stopped working, which is what sent me looking at issues #80418 and #86388 first.

Also worth noting that "off by default" reads as though a default can be changed, but enableArtifact is the only on-switch and it does not apply here.

Suggested resolutions

Any one of these would resolve it:

1. Grant the Artifact tool to sessions spawned by claude remote-control. These are user-driven interactive sessions on a machine the user is signed in on, which seems closer to the CLI case than to a headless SDK embedding.
2. Add an opt-in, either a claude remote-control flag or an env var the server passes to spawned sessions.
3. At minimum, document it: note the capability difference in the Remote Control docs and in the artifacts Availability table, and have Claude say the tool is unavailable in this session type rather than quietly writing a local file.

Related

• #80418 and #86388 report the Artifact tool missing from the registry with the same diagnostic signature, but both are account or org scoped rather than session-type scoped.
• #83976 and #84287 report claude remote-control (server mode) failing registration where claude --remote-control succeeds, which is separate evidence that the two paths diverge.