feat(shell): correct known shell-dialect errors in the tool output - #4141
Merged
trungutt merged 1 commit intoSep 3, 2026
Merged
Conversation
trungutt
marked this pull request as ready for review
September 3, 2026 09:38
dgageot
previously approved these changes
Sep 3, 2026
Collaborator
|
👋 This PR has merge conflicts with the base branch. Please rebase or merge the latest base branch and resolve them. I've moved it to draft and added |
The shell tool description already tells the model which interpreter runs its commands, but haiku-class models still emit POSIX syntax (`&&`, `grep`, `head`, `2>/dev/null`, `ls -la`) turn after turn under Windows PowerShell 5.1 — every attempt produces a fresh parse or parameter error, the model re-derives the dialect from scratch, and the same wrong syntax gets emitted again. Long agentic sessions burn dozens of tool calls this way before recovering. Scan the shell-tool output for the well-known error signatures those POSIX-isms produce and prepend a terse imperative hint above the raw output. The hint lands at the top of the tool result so the model sees it first, and the original output is preserved verbatim below so nothing about the debugging path is hidden. The hint is gated on the resolved shell (powershell / pwsh / cmd), not on a raw substring match: without that gate a docker logs pull from a Windows container, a grep against this repo, or a cat of a docs page that quotes the error string would all trip false positives on macOS/Linux hosts. Gating also makes each hint truthful — a "chain with &&" nudge is actively wrong when the resolved shell is PowerShell and the failure came from a child cmd.exe invocation.
trungutt
force-pushed
the
feat/shell-dialect-error-correction
branch
from
September 3, 2026 11:23
437b143 to
b3915a6
Compare
dgageot
approved these changes
Sep 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The shell tool description already tells the model which interpreter runs its commands (
shellToolDescription), but observed session traces show the model still emits POSIX syntax turn after turn under Windows PowerShell — every attempt produces a fresh parse or parameter error, the model re-derives the dialect from scratch, and the same wrong syntax gets emitted again.A representative trace across three consecutive turns in one session:
The description hint prevents turn 1 in some sessions but does not recover the sessions where the model ignores it. Long agentic sessions burn many tool calls this way.
What changes for the model
Scan the shell-tool output for well-known dialect-error signatures and prepend a terse imperative hint above the raw output:
The hint lands at the top so the model sees it first; the original output is preserved verbatim below so nothing about the debugging path is hidden.
Why gated on the resolved shell, not on a raw substring match
Without gating, a
docker logspull from a Windows container, agrepagainst a repo, or acatof a docs page that quotes the error string would all trip false positives on macOS/Linux hosts. Gating also makes each hint truthful — a "chain with;not&&" nudge is actively wrong when the resolved shell is PowerShell 7 (pwsh) or when the failure came from a childcmd.exeinvocation under a PowerShell parent.