Pin bun config for MCP server processes

[ashwin-ant]

Summary

• The action's entrypoints in action.yml already run bun with --no-env-file --config="${GITHUB_ACTION_PATH}/bunfig.toml" so runtime config resolves from the action directory rather than the current working directory. The bun-based MCP server processes (github_comment, github_file_ops, github_inline_comment, github_ci) were spawned with plain bun run <script>, so they picked up bunfig.toml and .env from whatever directory they happened to start in.
• Adds a small bunServerArgs() helper that builds the same invocation for all four servers, so they resolve config consistently with the entrypoints.
• The docker-based GitHub MCP server is unchanged.

Test plan

• bun test (805 pass) — new test asserts each bun server's args include the pinned flags before run
• bun run typecheck
• bun run format:check
• Manually confirmed with bun 1.3.x that --config alone still loads a cwd .env, and --no-env-file alone still reads a cwd bunfig.toml; both flags together read neither.

[claude]

LGTM — small, mechanical refactor that makes the four bun-based MCP servers use the same pinned bun invocation as the action entrypoints.

What was reviewed:

• Confirmed the new flags exactly mirror the entrypoint invocations in action.yml (--no-env-file --config="${GITHUB_ACTION_PATH}/bunfig.toml") and that bunfig.toml exists at the action root.
• Checked flag ordering — bun runtime flags placed before run is the correct and already-established pattern.
• Checked the GITHUB_ACTION_PATH read in the helper — behavior when unset is unchanged from the previous inlined template strings, and the variable is always set in the Actions runtime.
• New test asserts the exact args array for all four servers (github_comment, github_file_ops, github_inline_comment, github_ci); the docker-based server is untouched.

Extended reasoning...

Overview

The PR touches two files: src/mcp/install-mcp-server.ts and its test. It extracts a bunServerArgs() helper that builds the bun invocation for the action's four bun-based MCP servers, adding --no-env-file and --config=${GITHUB_ACTION_PATH}/bunfig.toml before run. This is a pure args-construction change — no server logic, tokens, or env plumbing is modified.

Security risks

This change is a mild security hardening rather than a risk: previously the MCP server processes (which carry GitHub tokens in their env) were spawned with plain bun run <script>, so bun would resolve bunfig.toml and .env from the process working directory — potentially the checked-out repository, where an untrusted bunfig.toml could, e.g., configure preload scripts. Pinning config resolution to the action directory closes that off and matches what the entrypoints in action.yml already do (lines 274-275, 416-417, 433-434). No new injection or data-exposure surface: GITHUB_ACTION_PATH is runner-controlled, and the args are passed as an array (no shell interpolation).

Level of scrutiny

Moderate — MCP server spawning is on a sensitive path (these processes hold GitHub tokens), but the change is small, mechanical, and consolidates four previously-duplicated inline arg arrays into one helper that mirrors an established pattern. I verified bunfig.toml exists at the repo root (intentionally minimal, as its comment states) and that the flag ordering (runtime flags before run) matches the entrypoint usage. The behavior when GITHUB_ACTION_PATH is unset is unchanged from before (template string yields undefined/... either way), and the variable is guaranteed in the Actions runtime.

Other factors

The new test asserts the exact args array for all four servers in one config that activates them all (PR context + commit signing + inline-comment tool + workflow token), and the existing GITHUB_ACTION_PATH test still passes via toContain. The author's test plan reports 805 passing tests, typecheck, and format check, plus a manual verification that both flags are needed together. The bug hunting system found no issues, and there are no outstanding reviewer comments on the timeline.