safe-bash 0.1.423: Bun-hosted Miniflare recreation stalls after output-budget abort

[kamilio]

A safe-bash/safe-fs upgrade from 0.1.70 to 0.1.423 exposes a Worker recreation failure in our Bun-hosted Miniflare tests after a shell output-budget abort. The same new-version lifecycle runner completes under Node. This appears to involve Bun/Miniflare subprocess or stream cleanup; we have not established that safe-bash command semantics or production Workers are broken.

This is separate from #649's portable export/provider API gaps.

Controlled comparison

We copied the original application shell sources into an isolated temporary package and kept the same Worker fixture, assertions, Wrangler bundling, compatibility flags, and backend harness. Only the temporary safe-bash and safe-fs dependency versions changed between these two runs:

Original shell sources	Dependencies	Paired Worker tests
Unchanged	safe-bash + safe-fs 0.1.70	11 passed, 45 assertions, 7.01s
Unchanged	safe-bash + safe-fs 0.1.423	First 8 passed; next Worker readiness timed out, 17.59s

The first test file covers tee, append, split UTF-8, binary output, and two output-budget failures. After disposing that Miniflare instance, the next file creates a new Worker for redirection tests. With 0.1.423 it stalls at worker.ready. Omitting the two budget-abort cases lets the paired tests pass. A same-file dispose/recreate experiment also reproduced the readiness timeout, so the file boundary itself is not required.

The failing command is:

curl https://download.example.com/large | tee /keep.txt | wc -c

The host returns a 1 MiB binary response. The shell's output budget is 64 KiB, and the request correctly rejects with Shell limit exceeded: maxOutputBytes. Failure occurs later when recreating a Worker, rather than in that assertion.

Bun versus Node lifecycle isolation

Using the same actual Wrangler-bundled shell fixture and a minimal Miniflare host loop:

• Bun: iterations 0–5 complete request, expected budget rejection, and disposal; iteration 6 times out awaiting readiness.
• Node: all 10 iterations complete successfully.
• An earlier three-iteration Bun run surfaced node:child_process #createStdioObject connect ENOENT; another three-iteration run passed. The failure is timing-sensitive, not guaranteed on every short run.

Observed diagnostic:

workerd/server/server.c++:6811: error: ... Broken pipe; fd = 3
...
Worker readiness timed out

The reduced host runner below was verified against our application shell fixture. It is not yet a standalone safe-bash-only reproduction: shell-worker.js is the existing Wrangler bundle, whose POST endpoint constructs a fresh shell, executes {script}, returns the result, and converts thrown limits to {error}. Its curl transport uses Worker fetch; the dummy TILES binding is not reached by this rejected pipeline, so native application storage is not needed for this reduced path.

import { readFileSync } from 'node:fs';
import { Miniflare, Response } from 'miniflare';

const script = readFileSync('./shell-worker.js', 'utf8');
for (let i = 0; i < 10; i++) {
  const worker = new Miniflare({
    modules: true,
    script,
    compatibilityDate: '2025-01-01',
    compatibilityFlags: [
      'nodejs_compat_v2',
      'global_fetch_strictly_public',
      'enable_nodejs_http_modules',
    ],
    cf: false,
    bindings: {
      EXECUTE_SHELL_NETWORK_ENABLED: 'true',
      AGENT_ENTITY_INTERNAL_TOKEN: 'test',
      TEST_AGENT_ID: 'agent_test',
    },
    serviceBindings: { TILES: () => new Response('ok') },
    outboundService: {
      node(request, response) {
        const bytes = new Uint8Array(1024 * 1024).fill(255);
        response.writeHead(200, {'content-type': 'application/octet-stream'});
        response.write(bytes, () => response.end(bytes.subarray(bytes.length)));
      },
    },
  });
  const deadline = setTimeout(() => {
    console.error('timeout', i);
    process.exit(1);
  }, 5000);
  console.log('ready', i, String(await worker.ready));
  const result = await worker.dispatchFetch('https://shell.test/', {
    method: 'POST',
    body: JSON.stringify({
      script: 'curl https://download.example.com/large | tee /keep.txt | wc -c',
    }),
  });
  console.log(await result.text());
  await worker.dispose();
  clearTimeout(deadline);
  console.log('disposed', i);
}

Run the same .mjs file with bun and node. The normal paired suite uses a 10-second readiness deadline; the reduced runner uses 5 seconds.

Environment

• macOS arm64
• Bun reports 1.3.11; test banner: 1.3.11-canary.1 (687700d8)
• Node 22.23.2
• Miniflare 4.20260708.1
• workerd 1.20260708.1
• Wrangler 4.110.0, actual deploy --dry-run bundle
• Worker compatibility date and flags as shown above

Requested guidance

Please help identify whether changed abort/stream cleanup in safe-bash or safe-fs triggers a Bun/Miniflare lifecycle defect, and establish the supported Worker/Bun test path. A minimized upstream regression test should cover output-limit rejection followed by disposal and repeated Worker creation. We are not requesting weaker output limits, skipped failure cases, or treating the successful Node run as proof that the Bun integration is healthy.

[kamilio]

I have not independently reproduced this lifecycle failure, so I am not changing abort/stream cleanup or weakening limits based on it. The reduced host runner still depends on the unprovided application bundle shell-worker.js. The available host here is Linux with Bun 1.3.8, rather than the reported macOS arm64 Bun 1.3.11-canary.1 profile. Real Miniflare/workerd checks for #649 now pass under Node, but that is explicitly not evidence that this Bun recreation issue is healthy. Please attach the minimized Worker bundle/source or a standalone public-package reproduction so the same abort → dispose → recreate sequence can be compared without guessing about application adapters. Keeping this issue open.

[kamilio]

Validation update (September 8): a bounded Linux x64 reproduction using the installed standalone candidate, Miniflare 4.20260708.1, compatibility date 2026-07-01 and nodejs_compat now reproduces a recreation stall under Bun 1.3.8: three cycles completed with the expected maxOutputBytes refusal and disposal, then the fourth readiness check timed out after 5 seconds with Broken pipe, fd=3. The identical Node 22.23.2 run completed all ten cycles. The mocked workload was a 1 MiB response through curl → tee → wc with a 64 KiB output limit; networking was disabled at the container boundary.

Two no-SafeBash Bun controls each completed ten cycles: (A) static response with no outbound fetch, and (B) mocked 1 MiB fetch, bounded 64 KiB read, stream cancellation, constant response, then disposal/recreation. These passing controls do not establish that this is merely a Bun issue, and the failing candidate does not yet establish the reported package-upgrade causality. The original macOS/Bun-canary application bundle remains unavailable. Keeping this issue open while narrowing the cause; no speculative cleanup or budget changes have been applied.

[kamilio]

Further minimized: no SafeBash code, shell execution, output abort, or command cleanup is needed for the observed failure.

Control C replaces the candidate with a static Worker plus an inert comment, matching its exact 1,053,988 UTF-8 bytes. Under Linux x64 / Bun 1.3.8 / Miniflare 4.20260708.1 / workerd 1.20260708.1, four cycles completed and the fifth timed out awaiting readiness after 5 seconds, with the same Broken pipe, fd=3 diagnostic. Node 22.23.2 completed 10/10. Every completed cycle returned 200 / ok, made zero outbound requests, and disposed successfully. The container had networking disabled.

This isolates an upstream host/configuration-transfer-sized reproduction; it does not yet identify the faulty Bun/Miniflare/workerd component or reproduce the original macOS/Bun-canary comparison. No speculative SafeBash cleanup patch is justified by this evidence. Keeping the issue open for that remaining attribution/support question.

The exact tested Worker can be generated with:

import { writeFileSync } from 'node:fs';
writeFileSync('control-worker.js', "export default { fetch() { return new Response('ok', {headers:{'x-read-bytes':'0'}}); } };\n/*" + "x".repeat(1053893) + "*/");

Worker SHA-256: 7b26032635dc0bc23da3b77fc7b3649c1781aadd6e6e90a09a7491614c3703dc.

Save the following exact executed host runner as control-runner.mjs, install the exact Miniflare version in that isolated directory, then compare bun control-runner.mjs < control-worker.js with node control-runner.mjs < control-worker.js. Use an outer process supervisor to clean up child processes after its failure exit, as our container supervisor did.

import {readFileSync} from 'node:fs';
import {Miniflare} from 'miniflare';
const script=readFileSync(0,'utf8');
const profile=typeof Bun==='undefined'?'Node '+process.version:'Bun '+Bun.version;
console.log(JSON.stringify({event:'profile',control:'C',profile,platform:process.platform,arch:process.arch,scriptUtf8Bytes:Buffer.byteLength(script,'utf8')}));
for(let cycle=0;cycle<10;cycle++){
 const started=performance.now();let phase='construct';let requests=0;
 const timer=setTimeout(()=>{console.error(JSON.stringify({event:'cycle-timeout',control:'C',profile,cycle,phase,elapsedMs:performance.now()-started}));process.exit(124);},5000);
 try {
  const worker=new Miniflare({modules:true,script,compatibilityDate:'2026-07-01',compatibilityFlags:['nodejs_compat'],cf:false,outboundService:{node(request,response){requests++;const bytes=new Uint8Array(1048576).fill(255);response.writeHead(200,{'content-type':'application/octet-stream'});response.write(bytes,()=>response.end(bytes.subarray(bytes.length)));}}});
  phase='ready';await worker.ready;const readyMs=performance.now()-started;
  phase='request';const response=await worker.dispatchFetch('https://shell.test/',{method:'POST'});const text=await response.text();const readBytes=response.headers.get('x-read-bytes');
  console.log(JSON.stringify({event:'response',control:'C',profile,cycle,readyMs,requests,status:response.status,text,readBytes}));
  if(response.status!==200||text!=='ok'||readBytes!=='0'||requests!==0)throw new Error('Expected static response and zero outbound requests');
  phase='dispose';await worker.dispose();clearTimeout(timer);
  console.log(JSON.stringify({event:'disposed',control:'C',profile,cycle,elapsedMs:performance.now()-started}));
 }catch(error){console.error(JSON.stringify({event:'failure',control:'C',profile,cycle,phase,error:String(error?.stack??error)}));process.exit(2);}
}
console.log(JSON.stringify({event:'control-pass',control:'C',profile,cycles:10}));

The outbound mock remains configured to preserve the host setup, but the static Worker never calls it. This is a size-matched negative control, not a claim that every large script or every Bun run fails.

[kamilio]

Upstream cross-reference review (September 8, 2026): oven-sh/bun#34785 reports intermittent Linux extra-stdio failures during repeated Chromium launches, with a passing Node comparison. It is related evidence, not the same Miniflare/large-static-script reproduction. oven-sh/bun#31932 specifically addresses Windows parent-to-child extra-pipe writes; that does not establish a fix for our Linux control C. cloudflare/workers-sdk#12025 explicitly describes its restart-stream cleanup fix as speculative because the original report lacked a reproducible case. cloudflare/workers-sdk#14086 fixes an IPv6-disabled localhost inspector bind problem, not a general config-transfer/recreation failure. None of these establishes the faulty component or a fixed version for our minimized witness or the original macOS profile. No upgrade or SafeBash workaround is being presented as a validated fix; the prior no-SafeBash control remains the strongest local evidence.

[kamilio]

September 9 validation refresh: the exact immutable no-SafeBash Control C (1,053,988 UTF-8 bytes, SHA-256 7b26032635dc0bc23da3b77fc7b3649c1781aadd6e6e90a09a7491614c3703dc) completed 10/10 recreation cycles under both Bun 1.3.8 and Node 22.23.2 in this single bounded attempt. Miniflare/workerd pins, compatibility settings, 5-second cycle deadlines, 2 GiB limit, and network isolation were retained; all requests returned 200/ok and outbound requests remained zero. The prior intermittent failure is preserved, not disproved. This static control executes no SafeBash and is not a claim that version 0.1.502 or the original macOS/Bun-canary integration is healthy. Component attribution and the original application reproduction remain unresolved; no speculative SafeBash cleanup change or closure is justified.