Persistent Bash timeout message should not diagnose OOM

[alexzhu0]

Summary

At upstream master commit 47f943859bef60e4160492346772ded9b24f765a, the persistent Bash timeout-handling path renders a timeout-or-OOM diagnosis even though that code path has only deadline evidence. It does not observe a process exit status, kernel event, cgroup event, or memory evidence that could establish an OOM.

Minimal reproduction

• The focused package test uses the timeout stub (wait-for-abort) and verifies the rendered timeout result.

• The assembled JSON-RPC scenario asks Bash to run exactly:

  printf 'BEFORE_TIMEOUT\n'; sleep 60

  It captures BEFORE_TIMEOUT before the 15-second snapshot deadline.

Root cause

The timeout-handling code path establishes only that its deadline fired; it does not observe process exit status, kernel events, cgroup events, or memory evidence that could establish an OOM. The OOM alternative therefore overstates the available evidence.

Proposed correction

Replace only the first diagnostic line:

Old: Your command timed out after N seconds or experienced an OOM error. Below is partial output:
New: Your command timed out after N seconds. Below is partial output:

Deliberately unchanged: bounded partial-output handling, timeout rounding, reset behavior and guidance, shell lifecycle handling, configuration defaults, and terminal backend contracts.

Behavior preserved

Persistent Bash state before timeout is preserved. The assembled coverage also preserves bounded partial output; reset guidance; a fresh workspace current directory and environment; DSH_EXAMPLE_COUNT unset after reset; explicit exit 9; editor create, view, and replace behavior; and the final PERSISTENT_TOOLS_OK response.

Keyless assembled coverage

The persistent-tools snapshot runs the real JSON-RPC runtime, persistent Bash tool, terminal service, and terminal Bash backend. It replays only recorded model output, so it needs no model key. The ordinary interactive default remains 300 seconds; snapshots use 15 seconds.

Validation

Full verification at c3c17837a8d82e783a5047807dd8eb91580bd08e recorded the following results:

• pnpm exec vitest run packages/shell/tool-bash-persistent/tests/tools.spec.ts — passed, 17/17 tests.
• pnpm run test:snapshot examples/jsonrpc-agent/tests/sdk.snapshot.ts -t persistent-tools — passed, 1 test passed and 3 skipped.
• pnpm run test:snapshot — passed, 12 files passed; 115 tests passed and 1 skipped.
• pnpm run typecheck — passed.
• pnpm run doc-sync — passed, 28/28 gates.
• pnpm run lint — passed.
• git diff --check — passed with no output.

The final documentation-only commit, 8cdd11d423359409323d1cd072a461669a6d0981, then passed its scoped documentation checks, pnpm run doc-sync (28/28 gates), git diff --check, and the pre-push typecheck.

The same commands were retried on a host-backed runner only for sandbox restrictions on real /bin/ps, local IPC, listeners, temporary workspaces, and file watchers; those restrictions were not treated as product failures.

Optional reference implementation

If useful for evaluation, the fork branch and its seven separated commits are available below; this is reference material, not a request or expectation that the project accept a pull request or cherry-pick.

Branch: https://github.com/alexzhu0/deepseek-harness/tree/fix/persistent-bash-timeout-diagnostic

Core proposal, fix, coverage, and decision:

1. cf49b3d5f41842034a6b9eae81c6d6c40565a94e — docs(shell): propose timeout-only persistent bash diagnostic
2. 786f68b0c09062aa1832702a9449cffa277e1c4d — fix(shell): report persistent bash timeouts accurately
3. d04e3fe6317f7ed30ee1c5d6fb7a7f3a0f065467 — test(shell): snapshot persistent bash timeout reset
4. fac441f1fc68fc19e0dd249f96eb6b849b9bc6e3 — docs(shell): record timeout-only diagnostic decision

Generated and review-documentation follow-ups:

5. 06a807b1cea315d5a425bc7f0a080d9d483d348e — docs(config): refresh persistent bash catalog
6. c3c17837a8d82e783a5047807dd8eb91580bd08e — docs(shell): separate timeout verification evidence
7. 8cdd11d423359409323d1cd072a461669a6d0981 — docs(shell): link persistent bash package reference

I did not open a PR because CONTRIBUTING.md says the project cannot accept external pull requests at the moment and directs bug reports to GitHub Discussions.

Would the timeout-only wording match the maintainers' intended diagnostic boundary?

[alexzhu0]

Following up once for visibility. The tested reference branch remains available, and I’m happy to rebase it or provide additional focused evidence if this timeout-only diagnostic matches the intended behavior. Per CONTRIBUTING.md, I’ll keep this in Discussions rather than opening a PR.