Bug: Command substitution denial is inconsistently applied and opaque

What happened?

When the agent runs a shell command containing command substitution ($(), backticks, <(), >()), the security check that should deny such commands is inconsistently applied:

• In some cases (compound commands where one sub-command matches an existing allow rule), the command is hard-denied with an opaque error message that does not mention command substitution. The user cannot override this even in YOLO mode, and the agent cannot understand why the command was rejected.
• In other cases (simple commands with no relevant permission rules), the command substitution check is entirely bypassed — the command is treated like any other non-read-only command and the user can approve it without any security warning.

What did you expect to happen?

The command substitution security check should be applied consistently — either always deny (with a clear reason), or always ask the user for confirmation (with a clear warning about command substitution). The current behavior where the check is sometimes applied and sometimes bypassed based on whether the user has configured permission rules is clearly unintended.

Additionally, when a command is denied due to command substitution, the error message should clearly state the reason, so both the user and the agent can understand and adapt.

Reproduction scenario

The 'deny' behavior is triggered when the PermissionManager has "relevant" rules for the command (i.e., some rules could potentially apply to the command context), but no rule actually matches the specific command containing command substitution. This most commonly happens with compound commands where one sub-command matches an existing allow rule (making the rules "relevant"), while another sub-command contains command substitution but doesn't match any rule.

Test command (in YOLO mode):

echo hello && python3 -c "print($(echo hello))"

Why this triggers the deny:

• The compound command is split into sub-commands: echo hello and python3 -c "print($(echo hello))"
• echo hello matches an existing Bash(echo *) allow rule → the PermissionManager considers its rules "relevant" to this command context
• python3 -c "print($(echo hello))" doesn't match any rule → evaluateSingle() returns 'default'
• For 'default' results on shell commands, resolveDefaultPermission() is called, which detects command substitution and returns 'deny'
• The most restrictive result ('deny') wins over 'allow' → the entire compound command is denied

What the agent sees (returned as tool error):

Tool "run_shell_command" is denied by permission rules.

What the user sees (rendered in the TUI):

  ╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
  │ x  Shell {"command":"echo hello && python3 -c \"print($(echo hello))\"","description":"Test compound command with substitution in YOLO mode"}  │
  │                                                                                                                                                │
  │    Tool "run_shell_command" is denied by permission rules.                                                                                     │
  ╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

Note: a simple command like python3 -c "print($(echo hello))" alone would NOT trigger the deny — it would get 'ask' (because the PermissionManager has no relevant rules for python3 and skips evaluation entirely). This inconsistency makes the behavior especially confusing.

Anything else we need to know?

Root cause analysis:

The inconsistency comes from the L3→L4 permission evaluation flow:

• L3 (ShellToolInvocation.getDefaultPermission()): Does NOT check for command substitution. AST analysis marks commands with substitution as non-read-only → returns 'ask'.
• L4 (PermissionManager.evaluate()): When hasRelevantRules() returns true (some rule could apply), evaluate() is called. For sub-commands where no rule matches ('default'), resolveDefaultPermission() detects command substitution → 'deny'. But when hasRelevantRules() returns false (no rules could apply at all), PM evaluation is skipped entirely and the command keeps its L3 'ask' — the command substitution check is never reached.
• L5: YOLO mode auto-approves 'ask' but does NOT override 'deny'.

This means the command substitution security check only fires when the PermissionManager is invoked (hasRelevantRules=true), but is completely bypassed when no rules are relevant. The hasRelevantRules() gate was likely intended as a performance optimization, but it inadvertently creates a security inconsistency.

Suggested fix:

• Change resolveDefaultPermission() to return 'ask' instead of 'deny' for command substitution, ensuring consistent behavior regardless of the user's rule configuration.
• Add a specific warning about command substitution in the confirmation prompt, so users can make informed decisions.
• Include the denial reason in the error message when a command substitution command is denied, so the agent can understand and adapt.

echo hello && python3 -c "print($(echo hello))"

Tool "run_shell_command" is denied by permission rules.

  ╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
  │ x  Shell {"command":"echo hello && python3 -c \"print($(echo hello))\"","description":"Test compound command with substitution in YOLO mode"}  │
  │                                                                                                                                                │
  │    Tool "run_shell_command" is denied by permission rules.                                                                                     │
  ╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯