[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.