0xdhx 1f6d827e48 fix(#2665): scrub config-location env in the #2624 in-process install block ...

Self-found during the rebase onto next, not from the review.

The base range added `describe('#2624 .gsd-source marker is rewritten before
staging reads it')`, which calls the real `install(true, 'claude')` IN-PROCESS
and sandboxes HOME/USERPROFILE/GSD_EXPLICIT_CONFIG_DIR — but not
CLAUDE_CONFIG_DIR. That is exactly the Blocker-1 shape this PR exists to close,
reintroduced in new code written after the round-1 review.

Measured on the rebased tree, same file, same commit:

  CLAUDE_CONFIG_DIR unset -> 50/50 pass
  CLAUDE_CONFIG_DIR set   -> 47/50, and a COMPLETE global install lands in it
                             (gsd-core/, agents/, skills/, hooks/, scripts/,
                             gsd-file-manifest.json, gsd-install-state.json,
                             .gsd-source, .gsd-profile)

The three failures are the honest symptom rather than the problem: the install
goes to the ambient config dir, so the assertions look for a marker under
tmpRoot that was never written there.

With scrubConfigLocationEnv() wired into the block's beforeEach/afterEach —
the same pattern the sibling block at :753 already uses — the file is 50/50
under BOTH conditions and leaks zero entries.

Worth stating plainly: CI cannot catch this class, since CI never has these
vars set. It surfaced here only because the rebase brought the base's new tests
under an ambient CLAUDE_CONFIG_DIR, which is the condition #2665's own
acceptance criterion runs under.

2026-08-08 05:50:36 -05:00

50 KiB

Raw Blame History

View Raw