| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
Here are some automated review suggestions for this pull request.
Reviewed commit: 6325b7270c
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Sorry, something went wrong.
There was a problem hiding this comment.
The oversized-input handling and replay regression coverage look good. One configuration edge case needs fixing before merge.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Bash PTC tools are meant to handle arbitrary-size input, but the preamble's
internal plumbing quietly assumes inputs stay well under the kernel's
ARG_MAX (~128KB) — which isn't a safe assumption for every PTC use case.
Problem
Three spots in the bash PTC preamble pass raw tool input to jq via
--argjson (a command-line argument), capped by ARG_MAX:
and the script aborts with "Argument list too long."
hit it silently instead — the error is swallowed, so a cached result never
matches, and the call re-executes on every replay round rather than
reusing it.
Fix
Read the input via stdin (pending-call write — stdin is free there) or
--slurpfile (the two matchers — stdin is already used for their primary
input) instead of argv, in all three spots.
Also makes tool_history's per-entry/aggregate byte caps in
replay-state.ts configurable via PTC_MAX_TOOL_RESULT_BYTES /
PTC_MAX_TOOL_HISTORY_TOTAL_BYTES (defaults unchanged), for deployments
whose tools return larger outputs.
Testing
run instead of re-issuing.