Skip to content

test(mcp): os.homedir spy in lifecycle.test.ts leaks across test files → 6 permission tests fail on CI #1042

Description

@sahrizvi

Symptom

The CI / TypeScript job (which runs the full bun test suite) fails intermittently on 6 tests in packages/opencode/test/permission/next.test.ts:

  • fromConfig - expands tilde to home directory
  • fromConfig - expands \$HOME to home directory
  • fromConfig - expands \$HOME without trailing slash
  • fromConfig - expands exact tilde to home directory
  • evaluate - matches expanded tilde pattern
  • evaluate - matches expanded \$HOME pattern

Failure output shows two DIFFERENT os.homedir() return values in the same test — one at test-execution time, one at expect().toEqual() time:

error: expect(received).toEqual(expected)
[
  {
    "action": "allow",
-   "pattern": "/tmp/mcp-lifecycle-home-Zz7Y0f/projects/*",
+   "pattern": "/tmp/mcp-lifecycle-home-VvysFV/projects/*",
    "permission": "external_directory",
  }
]

The mcp-lifecycle-home- prefix is the smoking gun — the two paths come from mkdtempSync(path.join(tmpdir(), "mcp-lifecycle-home-")).

Root cause

packages/opencode/test/mcp/lifecycle.test.ts:250 installs a spy on os.homedir in beforeEach but never restores it:

beforeEach(() => {
  spyOn(os, "homedir").mockImplementation(() => mkdtempSync(path.join(tmpdir(), "mcp-lifecycle-home-")))
  // …
})

There is no matching afterEach that calls .mockRestore() (per-spy) or mock.restore() (all mocks). When bun runs test files in the same worker process, the spy persists past lifecycle.test.ts and pollutes any downstream test that calls os.homedir(). Each new call inside the spy hits mkdtempSync again, so two calls in the same downstream test return two different random temp dirs — which is exactly what test/permission/next.test.ts observes.

Reproducibility

  • Passes locally in isolation (bun test test/permission/next.test.ts → 80/80). Local HOME is stable, no spy is installed.
  • Passes locally in isolation (bun test test/mcp/lifecycle.test.ts → clean).
  • Fails on CI when the full suite runs, because file order in the worker exposes the leak.

Impact

  • release.yml is unaffected — the release workflow runs test/branding/ + test/install/ only (see .github/workflows/release.yml:47), not the full suite, so tag builds ship green.
  • PR checks are affected — the required CI/TypeScript job fails on any PR whose test-run order exposes the leak, forcing an admin bypass or a re-run gamble. This bit PR release: v0.9.3 #1041 (v0.9.3 release PR).

Fix

Two clean options — pick whichever fits the file's style:

Option A — per-spy restore (explicit, mirrors the beforeEach setup):

import { afterEach, beforeEach, spyOn } from "bun:test"

let homedirSpy: ReturnType<typeof spyOn>

beforeEach(() => {
  homedirSpy = spyOn(os, "homedir").mockImplementation(() =>
    mkdtempSync(path.join(tmpdir(), "mcp-lifecycle-home-")),
  )
  // …
})

afterEach(() => {
  homedirSpy.mockRestore()
})

Option B — blanket restore (also cleans up any other spy installed during a test):

import { afterEach, mock } from "bun:test"

afterEach(() => {
  mock.restore()
})

Regression test

Add a smoke test that asserts os.homedir() returns the process's real home immediately after the lifecycle.test.ts suite completes:

// packages/opencode/test/mcp/lifecycle-spy-leak.test.ts
import { test, expect } from "bun:test"
import os from "os"

test("os.homedir spy from lifecycle.test.ts must not leak", () => {
  expect(os.homedir()).not.toMatch(/mcp-lifecycle-home-/)
})

Or, less surgical but more general — a bun:test hook in a top-level preload that runs mock.restore() at file boundaries.

Priority

Low-medium — no production impact, no data risk. Purely a CI/DX problem: it forces PR authors to either re-run the check hoping for a favourable file order or ask for an admin bypass on unrelated PRs. Fix is small and self-contained; regression test would prevent recurrence.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions