Before submitting
Area
apps/server
Steps to reproduce
-
Use the Claude provider on the desktop app, local connection, with skills or custom commands in ~/.claude/skills.
-
Open a thread and type /. Confirm the Provider group lists your commands.
-
Make the next capability probe unreadable. Save this as /tmp/slow-claude, chmod +x it, and set Settings → Providers → Claude → Binary path to it:
#!/bin/sh
for arg in "$@"; do
case "$arg" in
--version|auth) exec /usr/local/bin/claude "$@" ;;
esac
done
sleep 60
--version still answers, so the provider stays installed and the run reaches the capability probe. The SDK call then exceeds the 25-second timeout.
-
Wait for the next probe, up to 5 minutes.
-
Type / again.
In normal use no wrapper is needed. Any spawn failure or a probe slower than 25 seconds does the same thing — that is how I hit it.
Expected behavior
A probe that cannot be read leaves the known command list alone. The / menu keeps listing the provider commands from the last good probe.
Actual behavior
The Provider group is empty. Only the built-in /model, /plan, and /default remain, for at least 5 minutes, and the empty list is written to ~/.t3/caches/claudeAgent.json, so a restart does not clear it. It recovers only when a later probe succeeds.
The mechanism: probeClaudeCapabilities maps a failure or a 25-second timeout (CAPABILITIES_PROBE_TIMEOUT_MS) to undefined. In checkClaudeProviderStatus (apps/server/src/provider/Layers/ClaudeProvider.ts:930) that becomes
const slashCommands = capabilities?.slashCommands ?? [];
which reads "the CLI was unreadable this time" as "the CLI has no commands". ClaudeDriver caches that undefined for the full CAPABILITIES_PROBE_TTL of 5 minutes (ClaudeDriver.ts:156-163), and ProviderRegistry.persistProvider writes every published snapshot to the status cache unconditionally (ProviderRegistry.ts:311-330), so the empty list outlives the process. Nothing keeps the previous value: makeManagedServerProvider holds no prior snapshot.
Impact
Minor bug or occasional failure.
Occasional, but total while it lasts: every provider slash command disappears at once, which reads as "T3 Code lost my skills" rather than as a transient probe failure.
Version or commit
main @ ad117235b
Environment
macOS 26.0 (Darwin 27.0.0), T3 Code desktop dev build, Node v26.5.0, Claude Code CLI 2.1.233, @anthropic-ai/claude-agent-sdk 0.3.170, local connection.
Logs or stack traces
None. The failure is silent: probeClaudeCapabilities swallows the error via Effect.result, and the probe's stderr handler is () => {}, so nothing reaches the log.
Workaround
Wait for a probe to succeed, up to 5 minutes. A restart alone does not help, because the cached empty list is reloaded.
I have a fix and will open a pull request against this issue: keep the slash commands from the last probe that succeeded, and use them when a probe reports no capabilities. Auth still reports warning / unknown, so only the command list is reused.
Before submitting
Area
apps/serverSteps to reproduce
Use the Claude provider on the desktop app, local connection, with skills or custom commands in
~/.claude/skills.Open a thread and type
/. Confirm the Provider group lists your commands.Make the next capability probe unreadable. Save this as
/tmp/slow-claude,chmod +xit, and set Settings → Providers → Claude → Binary path to it:--versionstill answers, so the provider stays installed and the run reaches the capability probe. The SDK call then exceeds the 25-second timeout.Wait for the next probe, up to 5 minutes.
Type
/again.In normal use no wrapper is needed. Any spawn failure or a probe slower than 25 seconds does the same thing — that is how I hit it.
Expected behavior
A probe that cannot be read leaves the known command list alone. The
/menu keeps listing the provider commands from the last good probe.Actual behavior
The Provider group is empty. Only the built-in
/model,/plan, and/defaultremain, for at least 5 minutes, and the empty list is written to~/.t3/caches/claudeAgent.json, so a restart does not clear it. It recovers only when a later probe succeeds.The mechanism:
probeClaudeCapabilitiesmaps a failure or a 25-second timeout (CAPABILITIES_PROBE_TIMEOUT_MS) toundefined. IncheckClaudeProviderStatus(apps/server/src/provider/Layers/ClaudeProvider.ts:930) that becomeswhich reads "the CLI was unreadable this time" as "the CLI has no commands".
ClaudeDrivercaches thatundefinedfor the fullCAPABILITIES_PROBE_TTLof 5 minutes (ClaudeDriver.ts:156-163), andProviderRegistry.persistProviderwrites every published snapshot to the status cache unconditionally (ProviderRegistry.ts:311-330), so the empty list outlives the process. Nothing keeps the previous value:makeManagedServerProviderholds no prior snapshot.Impact
Minor bug or occasional failure.
Occasional, but total while it lasts: every provider slash command disappears at once, which reads as "T3 Code lost my skills" rather than as a transient probe failure.
Version or commit
main @ ad117235bEnvironment
macOS 26.0 (Darwin 27.0.0), T3 Code desktop dev build, Node v26.5.0, Claude Code CLI 2.1.233,
@anthropic-ai/claude-agent-sdk0.3.170, local connection.Logs or stack traces
None. The failure is silent:
probeClaudeCapabilitiesswallows the error viaEffect.result, and the probe'sstderrhandler is() => {}, so nothing reaches the log.Workaround
Wait for a probe to succeed, up to 5 minutes. A restart alone does not help, because the cached empty list is reloaded.
I have a fix and will open a pull request against this issue: keep the slash commands from the last probe that succeeded, and use them when a probe reports no capabilities. Auth still reports
warning/unknown, so only the command list is reused.