Menu
Back to Blog
Code AuditProduction Readiness

The 128 KiB Prompt: A Production Readiness Bug from Our Code Audit of an AI Agent Gateway

On Agent37's gateway, a prompt bigger than about 128 KiB sent to the Grok harness never ran. A customer who pasted a long document or log got a generic message, "Grok ended the turn before it completed", with nothing that explained why.

We found it during a code audit of the gateway and reported it. Agent37 shipped the fix as release 0.16.1 with a regression test and credited the report in the commit.

What the gateway is

Agent37's gateway is an open-source, MIT-licensed AI agent gateway: an HTTP API that sends turns to an agent on an instance and streams the results back. One request field, agent, picks the harness: Hermes, OpenClaw, Claude Code, Codex, OpenCode, Grok or Pi. Client code stays the same whatever runs behind it. The gateway runs each agent's CLI on the same machine.

The bug

We reviewed commit dbe5f81. The path:

  1. The gateway accepts request bodies up to 2 MB, set in server/app.ts.
  2. The Grok adapter passed the whole prompt to the Grok CLI as a single command-line argument (-p).
  3. Linux caps a single command-line argument at 128 KiB. Anything bigger makes the process fail to start.
  4. The adapter treated that start failure as "no output". There was nothing on stdout or stderr and nothing the error map could classify, so the turn ended with the generic message.

So any prompt between 128 KiB and 2 MB was accepted by the API and then failed without a reason. A real customer reaches that range by pasting one large document.

This bug is easy to miss. Short prompts work, so ordinary testing passes. It shows up only with real customer inputs, and when it does, the error says nothing useful. That is how a bug turns into support tickets nobody can explain.

The lesson was already in the codebase

The Pi adapter in the same repo, server/adapters/pi-adapter.ts, sends its prompt through stdin. Its comment says why: as a command-line argument, the prompt would be size-bound.

The hazard was documented and avoided in one adapter and not carried over to its neighbour in server/adapters/grok-adapter.ts. What we had to notice was that one adapter knew something the other did not.

The fix

Agent37 fixed it in release 0.16.1 (PR #38). The Grok adapter now writes the prompt to a temporary file that only its owner can read, passes the file path to the CLI with --prompt-file, and deletes the file when the turn ends.

Agent37's team checked the limit on a production host: a 127 KiB prompt worked, and a 128 KiB prompt failed. They added a regression test that sends a prompt of about 136 KB end to end, and credited the report in the commit message. Thanks to Agent37's team for the fix and the test.

What we did not prove

  • We did not run anything. This was a static review. The 127 KiB and 128 KiB check on a real host was done by Agent37's team, not by us.
  • We did not measure how often customers hit this in practice.
  • We did not know whether the Grok CLI could read a prompt from stdin. That affected the choice of fix, not the bug. Agent37 chose a file.

The pattern

In a codebase with several adapters behind one interface, each adapter tends to learn its own lessons. When one of them works around a hazard, the others often still have it.

We saw the same shape in our security review of Rome. There, Rome's email channel already blocked spoofed senders from reaching the trusted path, and the inbox lookup went around it. Across three reviews, the most useful findings sat in places where the code already knew better somewhere else.

Production readiness checklist

  • Compare your API's body limit with every limit downstream of it. Command-line arguments, environment variables, message sizes and database columns all have their own caps.
  • Do not put user input in a command-line argument when it can grow. Use stdin or a file instead.
  • Never turn a process start failure into "no output". Surface the real error so support can see what happened.
  • When you fix a hazard in one adapter or integration, check its siblings in the same change. The next adapter over usually has the same problem.
  • Test with real-sized inputs: a long document, a big log, a full transcript.

How we work

In a code audit, a finding does not have to be a vulnerability. A bug that customers hit and support cannot explain is worth reporting too, and we say which kind each finding is.

FAQ

What does "spawn E2BIG" or "Argument list too long" mean?

The operating system refused to start a process because its command-line arguments, or one of them, were too large. In Node.js it shows up as spawn E2BIG, in a shell as "Argument list too long". In this gateway the error was swallowed, so the user saw only a generic message.

What is the maximum length of a command-line argument on Linux?

A single argument is capped at 128 KiB. The total size of all arguments plus environment variables has a separate, larger limit. Agent37's team confirmed the single-argument cap on a production host: 127 KiB worked, 128 KiB failed.

How do you pass a large prompt to a CLI from Node.js or Python?

Send it through stdin or write it to a temporary file and pass the file path. That is what the gateway does now: the prompt goes to a file readable only by its owner, the CLI reads it with --prompt-file, and the file is deleted when the turn ends. Do not put user input in a command-line argument when it can grow.

What should a production readiness checklist for an AI agent include?

Compare your API's request limit with every limit downstream of it, test with real-sized inputs, and make sure a process that fails to start produces a real error instead of empty output. When one integration works around a hazard, check the others for the same one.

Does a code audit only look for security vulnerabilities?

No. A code audit also finds bugs that break the product for real users, like this one. We say which kind each finding is: this was a reliability and production readiness bug, with no data exposed and no access gained.

We do code audits and production readiness reviews of AI agent products and AI-generated codebases by hand, for reliability as well as security. Tell us about your product.