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

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.