Feature Request: Add utility parameters to Bash tool

Status Closed — not planned
Maintainer reply None cached
Activity 2 comments · opened Feb 18, 2026 · closed Mar 19, 2026

The Bash tool currently has limited control over execution context and output handling. Several parameters would significantly improve usability and reduce workarounds.

1. Output limiting: maxLinesCount + truncateMode

Problem: When only a portion of output is needed (e.g. end of test results), the only option is piping through tail/head — inconsistent with Claude Code's own guidelines discouraging unnecessary use of those utilities.

Proposed:

  • maxLinesCount: number — limit returned lines
  • truncateMode: "START" | "MIDDLE" | "END" — where to truncate

Precedent: Already implemented in execute_terminal_command and execute_run_configuration (JetBrains MCP server).

---

2. workingDirectory: string

Problem: Shell state (including current directory) does not persist between Bash tool calls. The workaround cd /path && command must be repeated in every call.

Proposed: An explicit workingDirectory parameter scoped to a single invocation, making calls cleaner and less error-prone.

---

3. env: Record<string, string>

Problem: Passing environment variables currently requires inlining them into the command string: KEY=value command. This is harder to read and reason about.

Proposed: A structured env object, e.g.:

{ "NODE_ENV": "test", "DEBUG": "1" }

---

4. separateStderr: boolean

Problem: stdout and stderr are currently merged, making it impossible to distinguish errors from normal output without redirecting 2>&1 or 2>/dev/null manually.

Proposed: When true, return stdout and stderr as separate fields in the response.

---

5. ignoreExitCode: boolean

Problem: Some commands return non-zero exit codes in non-error scenarios (e.g. diff returns 1 when files differ, grep returns 1 when no matches found). This can cause unnecessary noise or confusion.

Proposed: When true, treat any exit code as success.

---

6. stdin: string

Problem: Interactive commands requiring user input (e.g. confirmations) are currently difficult or impossible to handle cleanly.

Proposed: A stdin string passed to the command's standard input.

---

These parameters would reduce shell command complexity, improve output readability, and align the Bash tool more closely with other well-designed tools in the ecosystem.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗