[Bug]: Claude threads on orchestrator v2 should enable the Artifact tool by default

[jecrapo]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Start a new Claude thread with no CLAUDE_CODE_ARTIFACT set anywhere.
2. Ask the agent to publish something as an artifact.
3. The agent reports that it has no Artifact tool.

Expected behavior

Claude threads have the Artifact tool by default, as a terminal claude session on the same account does.

Actual behavior

#7452 was closed as a configuration issue, with the fix being CLAUDE_CODE_ARTIFACT=1 under Settings > Providers > Claude > Environment variables. That works. I'm asking you to reconsider the default for v2, because users don't find that setting on their own.

In SDK sessions (sdk-ts, sdk-py, sdk-cli), Claude Code doesn't register the Artifact tool unless CLAUDE_CODE_ARTIFACT is set. The tool is absent, not denied. The agent says it has no such tool, and nothing in T3 explains why. To fix it, a user has to know a variable name that appears only in this issue tracker.

I think T3 is the right place to opt in, for three reasons:

• The terminal CLI has artifacts on. T3 is an interactive client, and its users expect the same tools the terminal gives them.
• T3 already handles artifacts. [Bug]: Claude Code's artifact live-updates watcher is listed in the Agents panel as a working agent with a model and effort #13978 triaged the monitor_ws watcher that publishing an artifact starts. That work helps only the users who found the variable.
• /design is behind the same gate. The [Bug]: /design only manages consent in Claude threads and never runs the design skill #13511 triage traced the consent-only substitution to sdk_default_off and ended with "leave the code as-is unless we explicitly want Claude threads to opt into artifacts." This issue asks for that decision.

Following the #14322 triage, the change would set CLAUDE_CODE_ARTIFACT=1 on the environment that createClaudeAdapterV2 passes to the query, and only when the variable is unset. makeClaudeEnvironment stays as it is. An explicit CLAUDE_CODE_ARTIFACT=0 or CLAUDE_CODE_DISABLE_ARTIFACT=1 still turns the tool off.

If on-by-default is the wrong call, an Artifacts toggle in the Claude provider settings would still solve the discovery problem.

Impact

Major degradation or frequent failure

Version or commit

T3 Code 0.0.45-nightly.20261002.2572

Environment

macOS 27.0.1, Claude Code 2.1.287, Claude provider

Logs or stack traces

$ CLAUDE_CODE_ENTRYPOINT=sdk-ts claude -p --setting-sources project --output-format stream-json --verbose --max-turns 1 "ok" \
	| jq -c 'select(.type=="system" and .subtype=="init") | [.tools[]|select(test("Artifact"))]'
[]
$ CLAUDE_CODE_ARTIFACT=1 CLAUDE_CODE_ENTRYPOINT=sdk-ts claude -p --setting-sources project --output-format stream-json --verbose --max-turns 1 "ok" \
	| jq -c 'select(.type=="system" and .subtype=="init") | [.tools[]|select(test("Artifact"))]'
["Artifact","ArtifactComments","ArtifactData"]

Workaround

Set CLAUDE_CODE_ARTIFACT=1 under Settings > Providers > Claude > Environment variables, then start a new thread.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks for laying this out so clearly, @jecrapo, and for the init-list repro. Your reading is right. This is the product decision that open issue #13511 left open, so we're tracking it as an enhancement rather than a bug.

What's happening: Anthropic documents artifacts as off by default in Agent SDK sessions. Claude Code only registers the tool when CLAUDE_CODE_ARTIFACT is truthy. An interactive claude terminal isn't an SDK entrypoint, which is why the tool shows up there. T3 never sets the variable: makeClaudeEnvironment (apps/server/src/provider/Drivers/ClaudeHome.ts) copies the instance environment and adds CLAUDE_CONFIG_DIR when a home path is set, and that's it. The v2 path (createClaudeAdapterV2) builds its environment the same way. The workaround still works because the provider's environment variables are merged in first, which is why closed issue #7452 stays closed.

If we opt in: the placement you suggested is the right one. Set CLAUDE_CODE_ARTIFACT=1 on the environment createClaudeAdapterV2 passes to the query, only when it's unset, and leave makeClaudeEnvironment alone, since terminals, text generation, and the capabilities probe use it too. Explicit CLAUDE_CODE_ARTIFACT=0, CLAUDE_CODE_DISABLE_ARTIFACT=1, enableArtifact: false, and managed policy would all still win. A few side effects belong in the same decision:

• It's the same sdk_default_off gate as /design in [Bug]: /design only manages consent in Claude threads and never runs the design skill #13511, so that would change too.
• Publishing starts the monitor_ws watcher, which open issue [Bug]: Claude Code's artifact live-updates watcher is listed in the Agents panel as a working agent with a model and effort #13978 shows as a working agent in the panel.
• Claude Code opens a browser on the machine running the session unless CLAUDE_CODE_ARTIFACT_AUTO_OPEN=0. T3 hosts often aren't the user's desktop, so that default needs a decision too.
• API-key, Bedrock, Vertex, and Foundry sessions still can't publish, even with the tool registered.

Until then, CLAUDE_CODE_ARTIFACT=1 under Settings > Providers > Claude > Environment variables is the way to turn it on. I'm leaving this open so a maintainer can decide on the default.

[lingolooper-simon]

I'm a game developer, and artifacts are a big part of how my team works. In the Claude Code terminal I say "create me an artifact" and get a page with videos and images in it. That's essential for visual work: we use these pages to give each other feedback and work on things together.

In T3 Code the same request fails, and the agent doesn't know why. It told me the upload tool "comes from the Claude app", "isn't connected" here, and can't be added. In fact it's Claude Code's own Artifact tool. Claude Code leaves it out of SDK sessions unless CLAUDE_CODE_ARTIFACT is set, and T3 doesn't set it. This also breaks the Claude Docs connector, which sends every file upload through the Artifact tool's upload_asset, so in T3 a Claude Docs page can't take a single file. Setting the variable in the Claude provider's environment fixes it, but the only place that's written down is this issue tracker.

I'd like Claude threads to have artifacts on by default. If that's too broad a change, an Artifacts toggle in the Claude provider settings would solve it for us.

[seth-dixon]

Note

Drafted by Claude Opus 5.5 in Claude Code (via T3 Code); reviewed and posted by @seth-dixon.

#28410 provides Claude threads the Artifact tool by default as a byproduct of switching CLAUDE_CODE_ENTRYPOINT from sdk-ts to t3-code. Was looking into this for myself and wanted to share what I found if at all helpful.

Artifacts are on by default

#28410 sets CLAUDE_CODE_ENTRYPOINT=t3-code. Claude Code's sdk_default_off gate matches only sdk-ts, sdk-py, and sdk-cli, so T3 sessions no longer hit it. I replayed the Agent SDK's launch command (--output-format stream-json --verbose --input-format stream-json, without --print) on Claude Code 2.1.316. The session was signed in to claude.ai, and CLAUDE_CODE_ARTIFACT was unset.

Entrypoint	Artifact tool	Publish
sdk-ts (before #28410)	Missing	Not possible
t3-code (now)	Present	Returns a claude.ai link

Live updates are off

Under t3-code, the publish result says:

Live subscription: none — this is a print (-p), cloud, subagent, or teammate session, which does not keep track of new versions of this artifact published elsewhere (only the main conversation of a local interactive, background, or TypeScript/Python Agent SDK session does).

Under sdk-ts with CLAUDE_CODE_ARTIFACT=1, the same publish skips the subscription only because the live-subscribe feature flag is off in the cached config. With t3-code, Claude Code never starts the monitor_ws watcher, even after Anthropic turns that flag on. The artifact comment auto-replies in #24962 and the watcher handling in #13978 and #29331 depend on that watcher.

/design <brief> waits on Anthropic

On my Ultra account, /design <brief> still answers that it "only manages agent access". A plain interactive claude terminal gives the same answer on 2.1.316 and 2.1.317. Claude Code's debug log shows why: Artifact gates frozen: ... types=false type_create=false type_catalog=false. Anthropic controls the Design type on its servers and hasn't enabled it for this account. The /design command doesn't check the entrypoint, so T3 threads should get the Design type when an account does.

Not settled

• Browser auto-open: no browser opened in any run. My account also has the open gate off, so these runs don't answer the remote-host question from the triage.
• Gateway users: Claude Code never loads the Artifact tool in a session with ANTHROPIC_AUTH_TOKEN set because it treats that session as not signed in to claude.ai. T3 can't change that.

[brandon-gradient]

I also reached the same conclusion last night and was just searching for where I might report it this morning when I saw I was beaten to the punch.