Skip to content

10 lifecycle tests fail in any git worktree — the environment AGENTS.md mandates for workers has a permanently red baseline #243

Description

@edheltzel

Problem

10 tests fail inside any git worktree and pass on a normal checkout. AGENTS.md mandates that workers run in an isolated worktree, so every worker and every reviewer currently sees 10 spurious failures on a clean tree — which trains agents (and humans) to treat a red suite as normal.

The failing tests

All in the same family — bash-sourced lifecycle functions:

tests/opencode-integration.test.ts  (5)
  recall_configure_opencode_mcp preserves user customizations
    › preserves inline // comments, non-Recall MCP entries, and JSON5 trailing commas
    › A7: preserves https:// URLs and other `//` substrings inside string values
  recall_configure_opencode_mcp hardening (V-1, V-3, V-4) [RED]
    › V-1: malformed JSON → non-zero exit AND file left byte-identical
    › V-3: user custom keys on recall-memory survive refresh; RECALL_DB_PATH updated
    › V-4: mcp container as non-object → non-zero exit AND file unchanged

tests/pi-integration.test.ts (5) — the recall_configure_pi_mcp mirror of the above

Proof it is environmental, not a code regression

Run inside the worktree with every local change stashed (i.e. pristine main code, worktree environment):

 31 pass
  5 fail          <-- tests/opencode-integration.test.ts

Same commit, normal checkout at ~/Developer/Atlas/Recall:

 36 pass
  0 fail

Full suite: clean main = 1245 pass / 0 fail. Same code in a worktree = 1236 pass / 10 fail.

The delta is exactly these 10. Nothing in the diff under test was involved — this reproduces with an empty working tree.

Symptom detail

The harness (tests/opencode-integration.test.ts:566) is:

execFileSync('bash', ['-c',
  `source "${REPO}/lib/install-lib.sh" >/dev/null 2>&1 && recall_configure_opencode_mcp >/dev/null 2>&1`,
], { env: { ...process.env, OPENCODE_CONFIG_DIR: sandboxDir, RECALL_DB_PATH: join(sandboxDir, 'fake-recall.db') } })

Reproduced manually in a worktree, the function reports success and exits 0:

✓ Registered recall-memory MCP server in opencode.json
exit=0

…but the sandbox file is not updated — fake-recall.db never appears in it. The same harness against a normal checkout writes the file correctly. So the merge step silently no-ops while still reporting success, and the assertion (expect(after).toContain('fake-recall.db')) fails.

Two things worth noting for whoever picks this up:

  1. The function claims success on a write that didn't happen. Independent of the worktree trigger, that is its own defect — a silent-failure smell in _recall_jsonc_merge_mcp_entry worth hardening regardless.
  2. source ... && fn in the harness means a non-zero source would silently skip the function and present as "file unchanged". Ruled out here (source exits 0 in the worktree), but the harness would not distinguish the two causes — worth making it assert the source and the call separately.

Suspected trigger: something in the merge path resolves relative to the repo root / node_modules and behaves differently when RECALL_REPO_DIR is a worktree under .claude/worktrees/ whose node_modules resolves upward to the parent checkout. Not confirmed — the investigation stopped at proving it environmental.

Why it matters

  • AGENTS.md → worker flow requires an isolated worktree. So this is the default condition for automated work, not an edge case.
  • A permanently-red baseline destroys the signal a test suite exists to provide: a worker cannot tell "my change broke 10 tests" from "the usual 10".
  • It cost real time this session: 10 failures appeared on a diff that touched none of this code, and ruling it out required stashing everything and re-running pristine main inside the worktree.

Proposed fix

  • Reproduce: git worktree add /tmp/wt-repro && cd /tmp/wt-repro && bun test tests/opencode-integration.test.ts
  • Find why the jsonc merge no-ops under a worktree root (likely path/module resolution around RECALL_REPO_DIR)
  • Fix the silent-success: the merge must exit non-zero when it does not write
  • Harden the harness: assert source and the function call separately so "didn't run" ≠ "ran and wrote nothing"
  • Regression guard: run the suite from a worktree in CI, so worktree-hostility can't silently return

Acceptance

  1. bun test from a fresh worktree matches a normal checkout: 0 failures.
  2. recall_configure_opencode_mcp / recall_configure_pi_mcp exit non-zero if the target file is not written.
  3. CI exercises a worktree run.

Found 2026-07-15 during the #240 investigation (see #242 for the diff that surfaced it).

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs-triageMaintainer needs to evaluate this issuerisk:mediumtype:bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions