Sign up
View stargazersSign up

Claude provider hangs on Bash calls when a UI-dependent Claude Code mod (e.g. blast-radius) is installed#17531

opened20d agobyKkaovilai

Note

Responses generated with Claude

Problem

With the Claude provider, if the user has a Claude Code mod installed that holds tool.call and waits for input in a TUI pane, the session sticks on the tool call. Since 0.0.45 the user sees it stuck waiting for approval that cannot be given from the T3 Code UI.

Example: blast-radius. It registers on("tool.call", { tool: "Bash" }), and for rm -rf, git reset --hard, git clean, force push, and migrations it opens a Pane (or the AbovePrompt band) with Proceed/Cancel buttons and polls until a button onPress fires. If nobody answers, it denies after 10 minutes.

Why this happens (analysis, not yet verified by a headless repro)

  • T3 Code runs Claude via the Agent SDK query() (apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts, query options around L860-910). It sets no settingSources and no plugins, so the spawned claude loads user/project/local settings, including user-scope installed plugins/mods.
  • The mod's tool.call hook runs inside that claude process, before canUseTool. The process is headless: there is no TUI to host $.ui.open, so the Pane/band never renders and Proceed/Cancel can never be pressed.
  • The tool call therefore looks "running" in T3 Code until the mod's 10 minute hold limit expires and it returns { deny }.
  • bypassPermissions (full access) skips canUseTool but probably not tool.call mod hooks, so full-access threads are likely affected too.

Proposed workaround (small, generic)

Add a Claude provider setting, for example "Load Claude Code mods/plugins from user settings", wired to the SDK options (settingSources, plugins, or an enabledPlugins override). When off, T3 sessions do not load UI-dependent mods. No vendor-specific plugin id is hardcoded. Default behavior stays as-is so existing hook/plugin users are not broken; open question whether the default should flip.

Smaller alternative: detect enabled plugins at session start and show a warning that UI-dependent mods cannot render in T3 Code.

Long-term fixes

  1. Upstream in Claude Code: headless/SDK sessions should not let a mod wait on UI that cannot exist. $.ui.open should report no UI available (and mods should fail open or deny immediately) instead of hanging. Worth reporting to anthropics/claude-code.
  2. Native risk gate in T3 Code: classify risky Bash commands (rm -rf, git reset --hard, force push, migrations) and show the blast-radius report on the existing approval card, via canUseTool plus an SDK PreToolUse hook so it also covers bypassPermissions. Larger scope and overlaps with Claude Code permission rules, so only if maintainers want it.

Repro

  1. Install the blast-radius mod at user scope (claude plugin marketplace add ./ then claude plugin install blast-radius@claude-code-playground-mods --scope user).
  2. Start a Claude thread in T3 Code and ask it to run rm -rf build in a throwaway repo.
  3. Tool call stays running with no way to approve; it is refused after about 10 minutes.

Happy to send a PR for the generic setting if that direction sounds right.

JJulius Marminge8d ago

Reproduced on Linux with the real web dev server at b5a226e49c, Claude Code 2.1.303, Claude Opus 5.5, and blast-radius 0.1.0 installed at user scope in an isolated CLAUDE_CONFIG_DIR.

In a throwaway repository containing build/sample.txt, I asked a new Claude thread to run exactly rm -rf build. Full access also reproduces: T3 stays on “Running rm”, the file remains, and the provider transcript emits system/ui_panes for blast-radius, followed by system/ui_invalidate, without a tool result. A separate headless Claude CLI run produces the same pane events and hold. I did not wait for the ten-minute timeout.

No matching duplicate found among 948 open issues scanned in 19 pages through the 90-day cutoff. The checkout uses the locally available origin/main; refreshing main over GitCafe Git transport timed out, so latest-main verification remains incomplete.

Leaving this open for maintainer review: changing the plugin's Proceed/Cancel gate or disabling that gate touches approval behavior, outside the automated fix scope. No code changes or PR.

Claude thread held on Running rm with no Blast Radius approval controls

JJulius Marminge8d ago

Follow-up: git ls-remote origin refs/heads/main completed and returned b5a226e49c, matching the tested checkout. The reproduction is on current main.

Kkaovilai8d ago
Synced from GitHub

Would really love to learn your repro setups for issue triaging. Seems very efficient and effective

JJulius Marminge7d ago

Confirmed again on Linux at 3b95e7831b, with Claude Code 2.1.303, Opus 5.5, and blast-radius 0.1.0 installed at user scope in an isolated config directory. In the real web client, rm -r build emits a Blast Radius pane focus request, but T3 remains on “Running rm” without controls; the fixture stays intact. This also happens in full access. Runtime transcript.

The earlier approval-scope handoff is superseded by this triage run. No matching duplicate found among 881 open issues scanned through the 90-day cutoff.