You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Persistent shells blame a command deadline on a possible OOM the runtime never observed
#3926
A small one, and one you have already spotted yourselves — there is a // TODO on the exact line. Present in 0.1.1-rc.2.
What happens
Both persistent shells reach this branch only when timeoutOf() reports that the command deadline fired:
consttimedOut=timeoutOf(commandDeadline.signal,TIMEOUT_CODE)if(timedOut!==undefined){
...
// TODO: Report a timeout only; this signal does not establish an OOM.`Your command timed out after ${Math.round(timedOut.timeoutMs/1000)} seconds or experienced an OOM error. Below is partial output:`,
That signal establishes exactly one thing — the deadline expired. It says nothing about memory. The message nevertheless hands the model a memory-exhaustion hypothesis the runtime never observed.
Both copies are identical:
file
line
packages/shell/tool-bash-persistent/src/index.ts
347
packages/shell/tool-pwsh-persistent/src/index.ts
~391
Why it is worth the two-line change
This string is written for a model, and it misdirects the reader it is aimed at. A model told its command may have OOM'd reasonably responds by shrinking batch sizes, splitting work, or lowering concurrency. The actual remedy for a deadline is the opposite kind of move — a longer timeout, or less work per call.
So the wrong hypothesis does not merely add noise; it points remediation in a direction that cannot help, on a path the agent hits precisely when it is already struggling.
Suggested fix
Report the timeout, and delete the speculation:
`Your command timed out after ${Math.round(timedOut.timeoutMs/1000)} seconds. Below is partial output:`,
The // TODO above the line already prescribes this, so this is really just a note that it is still there.
One detail worth copying if you take it: the tests pin the old wording, so they move with the change. We also added expect(text(result)).not.toContain('OOM') alongside, which keeps the speculation from creeping back in later.
Applied locally and it behaves as described. Happy to share the patch — noting we cannot open a pull request, per CONTRIBUTING.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
A small one, and one you have already spotted yourselves — there is a
// TODOon the exact line. Present in 0.1.1-rc.2.What happens
Both persistent shells reach this branch only when
timeoutOf()reports that the command deadline fired:That signal establishes exactly one thing — the deadline expired. It says nothing about memory. The message nevertheless hands the model a memory-exhaustion hypothesis the runtime never observed.
Both copies are identical:
packages/shell/tool-bash-persistent/src/index.tspackages/shell/tool-pwsh-persistent/src/index.tsWhy it is worth the two-line change
This string is written for a model, and it misdirects the reader it is aimed at. A model told its command may have OOM'd reasonably responds by shrinking batch sizes, splitting work, or lowering concurrency. The actual remedy for a deadline is the opposite kind of move — a longer timeout, or less work per call.
So the wrong hypothesis does not merely add noise; it points remediation in a direction that cannot help, on a path the agent hits precisely when it is already struggling.
Suggested fix
Report the timeout, and delete the speculation:
The
// TODOabove the line already prescribes this, so this is really just a note that it is still there.One detail worth copying if you take it: the tests pin the old wording, so they move with the change. We also added
expect(text(result)).not.toContain('OOM')alongside, which keeps the speculation from creeping back in later.Applied locally and it behaves as described. Happy to share the patch — noting we cannot open a pull request, per CONTRIBUTING.
All reactions