POST /workspace-tools/execute holds one HTTP request open for queue wait plus execution (deadlineBudgetMs = queue budget + timeoutMs + 5 s). Behind a proxy with a request limit, that forces JOB_TIMEOUT below the proxy limit. The bridge then advertises maxCommandTimeoutMs = min(JOB_TIMEOUT, 300000), so the proxy decides the longest command anyone can run.
Concretely, a deployment behind Cloudflare (100 s request cut) runs with JOB_TIMEOUT=90000. Every foreground or background command, including builds, test suites and playwright, is capped at 90 s. Even then, a 90 s command plus up to 30 s of admission wait can exceed 100 s, and the proxy's 524 then cancels a command that was about to finish. Agents compensate with sleep N; check loops that hit the same cap: on one deployment, 125 foreground commands were SIGKILLed in 9 days, 81 of them sleep-and-check waits.
Proposal
Decouple execution from the request. For example:
execute accepts the command and returns an operation id once the command is admitted (or after a short synchronous window, so fast commands still return inline).GET /workspace-tools/operations/:id (or long-poll with a bounded wait below any proxy limit) returns progress and the final result.- Cancellation and deadline stay server-side, and the command's own
timeoutMs is no longer tied to JOB_TIMEOUT.
- Advertise the new maximum separately from any request timeout.
Acceptance
- With
JOB_TIMEOUT (request budget) at 90 s, a 10-minute command runs to completion and its result is retrievable.
- A client disconnect during a long poll does not cancel the command. An explicit cancel does.
- Existing synchronous clients keep working for commands that finish inside the synchronous window.
POST /workspace-tools/executeholds one HTTP request open for queue wait plus execution (deadlineBudgetMs= queue budget +timeoutMs+ 5 s). Behind a proxy with a request limit, that forcesJOB_TIMEOUTbelow the proxy limit. The bridge then advertisesmaxCommandTimeoutMs = min(JOB_TIMEOUT, 300000), so the proxy decides the longest command anyone can run.Concretely, a deployment behind Cloudflare (100 s request cut) runs with
JOB_TIMEOUT=90000. Every foreground or background command, including builds, test suites andplaywright, is capped at 90 s. Even then, a 90 s command plus up to 30 s of admission wait can exceed 100 s, and the proxy's 524 then cancels a command that was about to finish. Agents compensate withsleep N; checkloops that hit the same cap: on one deployment, 125 foreground commands were SIGKILLed in 9 days, 81 of them sleep-and-check waits.Proposal
Decouple execution from the request. For example:
executeaccepts the command and returns an operation id once the command is admitted (or after a short synchronous window, so fast commands still return inline).GET /workspace-tools/operations/:id(or long-poll with a bounded wait below any proxy limit) returns progress and the final result.timeoutMsis no longer tied toJOB_TIMEOUT.Acceptance
JOB_TIMEOUT(request budget) at 90 s, a 10-minute command runs to completion and its result is retrievable.