[BUG] Bash permission walker: "Unhandled node type" forces prompts on pipes/semicolons nested inside $(...) command substitution

Status Open
Reported on v2.1.126
Maintainer reply None cached
Activity 0 comments · opened Sep 14, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

The Bash permission walker's tree-sitter AST dispatcher fails to handle control-operator nodes (; / "list", | / "pipeline") when they occur
nested inside a $(...) command substitution, even though the same operators are handled fine at the top level of a command. This forces an
unnecessary manual approval prompt on a command whose every component is individually allow-listed — and in the semicolon case, leaks the walker's
internal fallback error string ("Unhandled node type: ;") directly into the permission prompt shown to the user.

This looks like a third variant of the same underlying gap already reported in #55170 (parenthesized subshell form (cmd1; cmd2)) and #47752 /
#56019 (heredoc+pipe combinations) — all three were closed as not_planned/duplicate by the stale-issue bot without an actual fix. Filing this to
document the $(...) substitution case specifically and flag that the underlying architectural issue is still open.

What Should Happen?

When every individual command inside a $(...) command substitution is already allow-listed (e.g. cat, wc, echo), a compound form of those
commands joined by ; or | inside the substitution should be auto-approved the same way it already is at the top level of a command — with no
prompt, and no raw internal error text ever shown to the user.

Error Messages/Logs

Unhandled node type: ;

Steps to Reproduce

With cat, wc, echo, pwd all individually allow-listed / auto-allowed (all are on the built-in read-only allowlist):

  1. Run: echo "x: $(pwd)"

→ Clean, no prompt. Single simple command inside $(...).

  1. Run: echo "x: $(cat file.txt 2>/dev/null)"

→ Clean, no prompt. Single command + redirect inside $(...).

  1. Run: echo "x: $(cat file.txt | wc -l)"

→ PROMPTS. Pipe nested inside $(...).

  1. Run: echo "x: $(echo a; echo b)"

→ PROMPTS, and shows the literal internal error "Unhandled node type: ;" as the reason for the prompt.

Every inner command (cat, wc, echo) is independently auto-allowed. Top-level use of ; and | outside any substitution is also handled correctly
and does not prompt. The failure is specific to a control-operator node appearing inside a $(...) subtree.

Suggested fix: either (1) extend the AST walker to recurse into $(...) (and backtick) command-substitution bodies the same way it already handles
top-level list/pipeline nodes, or (2) as a stopgap, catch the "unhandled node type" fallback case and present a generic "this command needs
approval" prompt instead of leaking the raw internal error string.

Related issues (same underlying gap, different syntactic forms, all closed by stale-bot without a maintainer fix):

  • #55170 — (cmd1; cmd2) subshell form → Unhandled node type: ; (closed, not_planned)
  • #47752 / #56019 — heredoc+pipe combinations → Unhandled node type: pipeline (closed, duplicate)
  • #47701 / #47706 — redirects → Unhandled node type: file_redirect (closed)
  • #46868 — feature request: auto-allow compound commands when every component is individually allowed (closed)

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.126

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_

View original on GitHub ↗