[Bug]:CLI truncates large output at 64KB when stdout is a pipe (forced process.exit() before stdout drains)

[badmoo]

Summary

When a command (e.g. mcporter call ... / mcporter list --schema --output json) prints a large result to a pipe, the output is silently truncated at exactly 65536 bytes (64KB). Writing the same result to a file (> out.json) produces the complete output.

Root cause: after the command finishes, closeRuntimeAfterCommand() schedules a forced process.exit() ~50ms later without waiting for stdout to drain. On POSIX, process.stdout writes to a pipe are asynchronous — console.log() queues the data in libuv and returns immediately. The kernel pipe buffer only holds ~64KB, so any remaining bytes are still in libuv's write queue when the process is killed, and the pipe reader never receives them. (Writes to a file are synchronous, which is why > file is unaffected.)

Reproduction

# stdout is a pipe -> truncated to 65536 bytes
mcporter call <server> <tool> ... | wc -c        # => 65536  (truncated)
mcporter call <server> <tool> ... | cat > out    # => 65536  (truncated)

# stdout is a file -> complete
mcporter call <server> <tool> ... > out.json     # => e.g. 71846 (complete)

Use any tool/list whose serialized output exceeds ~64KB.

Root cause (source pointers)

• src/cli/output-utils.ts — large result is emitted in one shot:

  console.log(JSON.stringify(value, null, 2));

  For a pipe this is a non-blocking process.stdout.write(); the data is queued in libuv and flushed asynchronously.

• src/cli.ts — const FORCE_EXIT_GRACE_MS = 50;

• src/cli.ts closeRuntimeAfterCommand() — after cleanup, a forced exit is scheduled (force-exit is on by default; opt out via MCPORTER_NO_FORCE_EXIT=1):

  const scheduleForcedExit = () => {
    if (shouldForceExit) {
      setTimeout(() => {
        process.exit(process.exitCode ?? 0);  // kills the process before stdout drains
      }, FORCE_EXIT_GRACE_MS);
    }
  };

There is no hardcoded 64KB limit in the source (65536 / 64 * 1024 / maxBuffer all have 0 matches); 64KB is the OS pipe buffer capacity. There is also no stdout drain handling anywhere (writableNeedDrain / once('drain') have 0 matches).

Why > file works

File writes are synchronous on POSIX and don't go through the pipe buffer, so the full payload reaches the fd before exit.

Timeline

t	event	stdout pipe state
T+0ms	console.log(72KB) returns	first 64KB lands in kernel pipe buffer (full); ~6KB still queued in libuv
T+0–1ms	finally -> closeRuntimeAfterCommand() -> runtime.close() + terminateChildProcesses()	—
T+1ms	setImmediate schedules 50ms timer	—
T+51ms	process.exit(0)	remaining ~6KB never flushed -> reader sees only 65536 bytes

Proposed fix

Flush stdout before the forced exit (no-op for TTY/file; only waits when a pipe write is backpressured), with a safety cap so a stalled reader can't hang the process:

setTimeout(() => {
  process.stdout.write('', () => {
    process.exit(process.exitCode ?? 0);
  });
}, FORCE_EXIT_GRACE_MS);

Environment

• mcporter 0.12.1
• OS: POSIX (pipe buffer 64KB); reproduces wherever stdout is a pipe

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 25, 2026, 3:25 PM ET / 19:25 UTC.

Summary
Keep open: current main still emits large CLI output in one shot and then schedules a 50 ms hard process.exit without waiting for stdio to drain. The issue is already paired with open candidate fixes at #215 and #216, so it should close only after one implementation lands.

Reproducibility: yes. the report gives pipe-versus-file commands for output above 64 KiB, and current source still writes via console.log before a 50 ms hard exit without stdio drain handling. I did not run a live pipe reproduction during this read-only review.

Root-cause cluster
Relationship: canonical
Canonical: #214
Summary: This issue is the canonical remaining report for the forced-exit stdio-drain truncation bug; the open PRs are candidate fixes rather than close evidence.

Members:

• fixed_by_candidate: fix: flush stdout before forced exit to avoid 64KB pipe truncation #215 - The PR uses closing references for this issue and proposes a bounded stdout/stderr flush with direct delayed-pipe proof.
• fixed_by_candidate: fix: flush CLI stdio before forced exit #216 - The bot PR also uses closing references for this issue and implements the same forced-exit stdio-drain repair class.
• partial_overlap: force-exit may truncate large stdout when mcporter is called via child_process #145 - The older closed issue reported forced-exit stdout truncation, but this issue refines the remaining drain-before-exit failure after the fixed grace-window approach.
• superseded: fix: avoid truncating stdout before forced exit #151 - The older closed unmerged PR proposed a grace-window fix for the earlier report, but it does not own the remaining pipe-drain behavior tracked here.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Next step
No new fix PR should be queued because #215 and #216 already reference this issue with closing syntax.

Review details

Best possible solution:

Land one verified bounded stdout/stderr drain implementation with delayed-pipe, stalled-reader, and broken-pipe regression coverage, then let the linked PR close this issue.

Do we have a high-confidence way to reproduce the issue?

Yes: the report gives pipe-versus-file commands for output above 64 KiB, and current source still writes via console.log before a 50 ms hard exit without stdio drain handling. I did not run a live pipe reproduction during this read-only review.

Is this the best way to solve the issue?

Yes: a bounded stdout/stderr flush before forced exit is the narrow maintainable fix while preserving the anti-hang fallback. The remaining choice is which open implementation and timeout behavior maintainers want to land.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Two overlapping open candidate PRs target the same forced-exit behavior, so maintainers need to choose one final implementation and timeout tradeoff rather than landing competing fixes.

Codex review notes: model internal, reasoning high; reviewed against 782e028abebc.

Label changes

Label justifications:

• P2: This is a normal-priority CLI correctness bug with a narrow source-backed failure mode and limited blast radius.
• impact:data-loss: The issue is about silently dropped stdout bytes from large command output when stdout is piped.

Evidence reviewed

What I checked:

• Current forced-exit path: closeRuntimeAfterCommand still calls terminateChildProcesses, computes shouldForceExit, and schedules process.exit(process.exitCode ?? 0) after FORCE_EXIT_GRACE_MS without any stdout or stderr flush step. (src/cli.ts:352, 782e028abebc)
• Large output emission path: JSON output is still emitted with console.log(JSON.stringify(value, null, 2)), matching the reported large single-write stdout path. (src/cli/output-utils.ts:126, 782e028abebc)
• No stdio drain handling found: Searches found the forced-exit and stdout paths but no writableNeedDrain or drain handling before the forced-exit timer in the affected CLI shutdown/output surface. (782e028abebc)
• Existing regression coverage is weaker than this report: The existing forced-exit integration test checks that JSON output is parseable and larger than 8192 bytes, but it does not exercise a delayed pipe reader or the 64 KiB pipe-buffer boundary described here. (tests/cli-force-exit-behavior.integration.test.ts:130, 782e028abebc)
• Linked candidate fixes are open: GitHub reports this issue has two open closing PR references: fix: flush stdout before forced exit to avoid 64KB pipe truncation #215 and fix: flush CLI stdio before forced exit #216.
• Contributor proof on linked fix: The contributor PR body and comments include before/after terminal proof showing delayed pipe output clamped to 65536 bytes before the fix and complete output after the fix, plus stalled-reader and EPIPE checks.

Likely related people:

• steipete: Blame and log history tie the forced-exit block, JSON output helper, and existing forced-exit integration test to release-era CLI work by this author. (role: introduced current behavior and prior area owner; confidence: high; commits: 023314cf31cd, e1a35f8d9177; files: src/cli.ts, src/cli/output-utils.ts, tests/cli-force-exit-behavior.integration.test.ts)
• vincentkoc: The most recent current-main commit touching src/cli.ts and src/cli/output-utils.ts was a CLI hardening pass by this author, though it did not add the missing drain behavior. (role: recent adjacent contributor; confidence: medium; commits: 7491ed5a857e; files: src/cli.ts, src/cli/output-utils.ts)
• badmoo: This person filed the refined 64 KiB pipe-truncation report and authored the proof-positive open candidate fix for the same shutdown path. (role: current repro and candidate-fix contributor; confidence: medium; commits: d083a017a187; files: src/cli.ts, tests/cli-stdout-pipe-truncation.integration.test.ts)
• yuhp: This person reported the earlier forced-exit stdout truncation case and opened the older closed patch that provides relevant history for the shutdown/output area. (role: prior related repro contributor; confidence: medium; commits: 31eaef8270cf; files: src/cli.ts, tests/cli-force-exit-flush.integration.test.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[clawsweeper]

🦞✅
Implementation PR opened: #216
Status: The implementation PR is open. Post-flight status: checks are not clean: build (windows-latest): FAILURE
Worker: https://github.com/openclaw/clawsweeper/actions/runs/28009624215