ctx_batch_execute corrupts heredoc commands by appending stderr redirection

[Noctivoro]

Summary

ctx_batch_execute corrupts shell commands that use heredocs because runBatchCommands() appends 2>&1 directly to each command string before passing it to the shell executor.

For a command like:

node - <<'NODE'
console.log('heredoc works')
NODE

ctx_batch_execute effectively executes:

node - <<'NODE'
console.log('heredoc works')
NODE 2>&1

That changes the heredoc terminator from NODE to NODE 2>&1, so the shell does not terminate the heredoc where intended. The batch result can then show (no output) or otherwise misleading indexed/search output even though the command itself is valid.

Reproduction

Call ctx_batch_execute with a heredoc command:

{
  "commands": [
    {
      "label": "heredoc node simple",
      "command": "node - <<'NODE'\nconsole.log('heredoc works');\nconsole.log(process.version);\nNODE"
    }
  ],
  "queries": ["heredoc works node version"],
  "timeout": 5000
}

Observed output includes an indexed section for the command, but the section body is empty / (no output).

For comparison, the same command works through ctx_execute(language: "shell", code: ...).

Expected behavior

ctx_batch_execute should execute the user's command string as provided. It should not append shell syntax after the command body because that can alter multiline shell constructs such as heredocs.

Stderr should still be captured and indexed alongside stdout.

Likely cause

Current upstream main still appears to append redirection in src/server.ts:

code: `${nodeOptsPrefix}${cmd.command} 2>&1`,

This appears in both the serial and parallel runBatchCommands() paths.

Suggested fix

Do not mutate the command with 2>&1. Instead:

1. Execute the command string as-is:

code: `${nodeOptsPrefix}${cmd.command}`,

2. Combine the executor's captured streams before formatting/indexing:

const combinedOutput = result.stderr
  ? `${result.stdout}${result.stdout && !result.stdout.endsWith("\n") ? "\n" : ""}${result.stderr}`
  : result.stdout;

formatCommandOutput(cmd.label, combinedOutput, onFsBytes)

Apply the same pattern in both serial and parallel paths.

Environment

• context-mode: 1.0.146
• npm latest checked: 1.0.146
• Platform observed: macOS / Pi coding agent

Impact

This is easy for agents to hit because ctx_batch_execute is recommended as the primary data-gathering tool, and heredoc-based Node/Python snippets are a common way to keep complex analysis code readable inside shell commands.

[Noctivoro]

Confirmed the proposed fix works locally.

I patched the active local server bundle and the built server file to stop appending 2>&1 to cmd.command, then combined the executor-captured stdout/stderr after execution before formatting/indexing.

Local patch shape:

function combineExecOutput(result) {
  const stdout = result.stdout || "";
  const stderr = result.stderr || "";
  if (!stderr) return stdout;
  if (!stdout) return stderr;
  return `${stdout}${stdout.endsWith("\n") ? "" : "\n"}${stderr}`;
}

const result = await executor.execute({
  language: "shell",
  code: `${nodeOptsPrefix}${cmd.command}`,
  timeout,
});

const formatted = formatCommandOutput(
  cmd.label,
  combineExecOutput(result),
  onFsBytes,
);

I applied the same approach to both serial and parallel runBatchCommands() paths.

Verification after reload:

1. Serial ctx_batch_execute with a Node heredoc that writes to stdout and stderr now returns both streams correctly.
2. A normal shell command in the same batch still returns normally.
3. Parallel ctx_batch_execute with Node and Python heredocs, each writing stdout and stderr, also returns both streams correctly.

Example passing result:

# heredoc stdout stderr after bundle patch

bundle patch heredoc stdout works
bundle patch heredoc stderr works

And parallel heredoc checks also passed:

# parallel heredoc one

parallel heredoc one stdout
parallel heredoc one stderr

# parallel heredoc two

parallel heredoc two stdout
parallel heredoc two stderr

One implementation note: in my local Pi install, the running MCP server used server.bundle.mjs, not only build/server.js, so I had to patch/reload the active bundle to verify behavior. For upstream, the source fix should be made in src/server.ts and then included in the generated bundle during release/build.