fix(relink): don't clobber foreign skills that share a gstack name by smblight · Pull Request #2119 · garrytan/gstack

smblight · 2026-06-26T15:57:20Z

Problem

Installing gstack with --prefix (or any later ./setup run) silently deletes a user's own flat-named skills when they share a name with a gstack skill. Concretely: a personal /qa or /review skill symlinked into ~/.agents/skills/ gets removed.

It's not a one-time hit — setup calls gstack-relink as a self-healing step on every run, so each upgrade re-deletes them.

Root cause

bin/gstack-relink → _cleanup_skill_entry() removed any flat-named entry matching a gstack skill name, with no check on where the symlink points:

if [ -L "$entry" ]; then
  rm -f "$entry"            # deletes foreign symlinks too

In prefix mode the deletion isn't even necessary — gstack installs under gstack-* names — so the removed flat entry was pure collateral.

Fix

Scope the cleanup to gstack-owned entries only: remove a flat entry just when its symlink (or its dir's SKILL.md symlink) resolves into the gstack install dir. This mirrors the provenance check setup's cleanup_old_claude_symlinks() already uses, and also handles installs not literally named gstack/ via an $INSTALL_DIR-prefix match.

Result: foreign skills sharing a gstack name are preserved; genuinely stale flat-mode gstack entries are still cleaned.

Tests

Two regression tests added to test/relink.test.ts:

prefix mode preserves foreign flat skills sharing a gstack name — covers both the directory-symlink shape and the real-dir-with-foreign-SKILL.md-symlink shape.
prefix mode still removes gstack-owned stale flat entries — guards against over-correcting.

Verified the first test fails on main (foreign /qa deleted → ENOENT) and passes with the fix. Full suite: 26 pass, 0 fail.

bun test test/relink.test.ts

gstack-relink's _cleanup_skill_entry deleted ANY flat-named skill entry matching a gstack skill name when switching prefix modes — including symlinks that point outside the gstack install. A user with a personal /qa or /review skill (e.g. symlinked into ~/.agents/skills/) would have it silently removed on every ./setup, because setup runs gstack-relink as a self-healing step. In prefix mode the deletion isn't even needed: gstack installs under gstack-* names, so the flat entry it removed was pure collateral. Scope the cleanup to gstack-owned entries only: delete a flat entry just when its symlink (or its dir's SKILL.md symlink) resolves into the gstack install dir. Foreign skills sharing a gstack name are now preserved, while genuinely stale flat-mode gstack entries are still cleaned. This mirrors the provenance check setup's cleanup_old_claude_symlinks() already uses. Adds two regression tests to test/relink.test.ts: one asserting a foreign flat skill (both the dir-symlink and real-dir-with-foreign-SKILL.md shapes) survives a prefix-mode relink, and a companion asserting a gstack-owned stale flat entry is still cleaned. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

trunk-io · 2026-06-26T15:57:25Z

Merging to main in this repository is managed by Trunk.

To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

time-attack · 2026-07-15T21:56:19Z

@smblight replace lexical cases with link parent aware path resolutin pls, there is potential for destructive execution with this

time-attack · 2026-07-15T22:40:03Z

@smblight Please replace lexical ownership checks with path-safe containment checks. Current logic can treat paths outside the installation root as owned and delete them.

@NikhileshNanduri

…one state root, gstack never clobbers a skill it did not create (#2802) * fix(freeze): hook reads the same state root /freeze writes — fails closed under GSTACK_HOME (#1459, #1509) check-freeze.sh resolved its state dir as ${CLAUDE_PLUGIN_DATA:-$HOME/.gstack} while every writer (/freeze, /guard, /unfreeze, /investigate) resolves through bin/gstack-paths, GSTACK_HOME first. With GSTACK_HOME set, /freeze wrote freeze-dir.txt under GSTACK_HOME, the hook read $HOME/.gstack, found no file, and allowed everything — a deny-tier boundary failing open. One resolver now: gstack_hook_state_root() in careful/bin/hook-extract.sh (already sourced by both check-freeze.sh and check-careful.sh) implements the exact gstack-paths chain, including the CLAUDE_PLUGIN_ROOT guard that keeps a CLAUDE_PLUGIN_DATA leaked from another plugin from redirecting our state. check-freeze.sh and gstack_hook_log_fire both call it; nothing spawns gstack-paths from a hook. Tests: the GSTACK_HOME deny regression, GSTACK_HOME-over-CLAUDE_PLUGIN_DATA precedence, plugin-root guard both ways, and a byte-parity check against bin/gstack-paths across six env combinations. Existing freeze tests now pass CLAUDE_PLUGIN_ROOT like a real plugin install would. Idea from PR #1509 (@NikhileshNanduri); implemented natively against the shared resolver rather than a second fallback chain. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(relink): never delete or link over a skill gstack does not own (#2119) gstack-relink runs on every ./setup. Its cleanup did `rm -rf` on any same-name entry whose SKILL.md was a symlink, with no readlink check, and its link step did `mkdir -p` then `ln -snf` onto any existing SKILL.md — on Linux that replaces a user's real file with a symlink into gstack (macOS refused by accident). setup's Windows mode-flip cleanup deleted any real dir whose name matched a gstack skill. A personal `qa` skill, or a fork installed under another path, was destroyed by the installer of a tool it never asked for. Ownership is now proven, never assumed. An entry is ours when it is a symlink resolving into INSTALL_DIR or RENDER_DIR, a real dir whose SKILL.md is such a symlink, or a real dir carrying the .gstack-owned marker setup now writes for Windows copy installs (legacy copies count when byte-identical to the source or carrying gen-skill-docs' AUTO-GENERATED header). Anything else — including an entry whose readlink fails — is foreign: left untouched, reported on stderr, and listed in relink's summary line. The same rule replaces setup's Windows name-match deletion; setup:1040 and gstack-uninstall:204 already gated on readlink, so this closes the last unguarded deleter of the class. Tests: foreign real dir in flat mode, foreign flat entry on a prefix flip, foreign directory symlink, RENDER_DIR-targeted entry (ours), marker-carrying copy (ours), marker-less copy (foreign); the Windows cleanup test now proves provenance three ways and keeps the user's own same-name skill. Idea and two regression cases from PR #2119 (@smblight); implemented on the destination entry, not only the symlink target. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(setup): Chromium bootstrap is best-effort and bounded — skills always register (#1900, #1901, #1902, #913, #2233) setup runs under `set -e`, and the Chromium bootstrap in section 2 sat ahead of skill registration in section 4 with a bare `bunx playwright install chromium`, an unbounded download, and an explicit `exit 1` after the post-install launch probe. On an offline, proxied, or AppArmor-restricted box the user ended with ZERO skills registered and a re-run that died at the same line; a wedged download hung setup indefinitely. Every browser failure now records a reason code in _PW_FAIL_REASON and setup continues: skipped (GSTACK_SKIP_PLAYWRIGHT=1, #913), chromium-install, chromium-install-timeout (the download is bounded by the existing _wait_with_deadline helper, default 600s, env GSTACK_PLAYWRIGHT_INSTALL_TIMEOUT, process tree killed via _kill_tree), chromium-install-locked (another setup holds the lock: this one registers skills and re-probes next time instead of exiting), windows-no-node, windows-node-modules, post-install-launch (with the GSTACK_CHROMIUM_NO_SANDBOX=1 hint for Ubuntu 24.04's userns policy, #2157). The daemon font refresh is skipped when Chromium is unavailable. The final summary names the skills that need the browser (/qa, /qa-only, /design-review, /browse, make-pdf, /pair-agent) and the fix for the recorded reason, and logs the reason code (never a path) through gstack-telemetry-log when telemetry is on. Tests: static invariants over the anchor-sliced block (no exit, every reason code, deadline helper, trap chaining, guarded refresh, summary contents) plus an integration harness that executes the real block with a stubbed probe and installer: install failure, hang killed at the deadline with the tree kill recorded, non-numeric knob fallback, live lock (continues, installer not run, lock preserved), stale lock reclaimed, post-install probe failure, and the skip flag. Credit @DavidMiserak (PR #1900) for the best-effort shape; re-implemented on the current block. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(designs): preserve the time-attack fork-port residual evaluation The read-only evaluation of what remains portable from time-attack/gstack (583 raw candidates, 415 canonical, 287 with a residual, 48 adversarially refuted, 14 standing) lived only on a throwaway VM. This records the report, the lite residual index, the absorbed/superseded ledger, the refuter verdicts, and SHAS.md with the fork tip, upstream HEAD, merge-base, and a sha256 per file, so every scheduled fix in this wave series traces to its evidence. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: file the fork-port residual deferrals and document the Chromium bootstrap knobs TODOS.md gains the seven items the CEO and eng reviews of the fork-port residual plan deliberately deferred (shared ownership helper, config-key reader tripwire, "pre-existing" vocabulary, opt-in reply_language, .auth.json writer removal, the fork-derived-change rule for CONTRIBUTING, hook slug parity audit), each with rationale, and updates the two residual bullets for PR #2232 and PR #2233 with their dispositions. README's Troubleshooting section explains the best-effort Chromium bootstrap and its three knobs. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(relink): canonicalize link targets before the ownership check Pre-landing review finding: the ownership gate compared readlink output textually against INSTALL_DIR and RENDER_DIR, so two shapes of gstack's OWN entries read as foreign and were left behind on a mode flip — a legacy relative link (`gstack/qa/SKILL.md`, resolved against $PWD instead of the link's directory) and an entry linked against the real path of a symlinked install dir (~/.claude/skills/gstack -> checkout). Both now resolve: relative targets anchor at the link's directory, the directory part is canonicalized with pwd -P (the basename stays verbatim so a dangling managed target is not misread), and both spellings of each root are accepted. Two regression tests. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(telemetry): one-shot setup events never sweep other sessions' pending markers gstack-telemetry-log finalizes every .pending-<session> marker that is not the caller's own as outcome:unknown and deletes it. setup's onboarding events (_setup_welcome, _setup_playwright) have no session of their own, so a Chromium bootstrap failure during a live skill session recorded a false unknown for that session and removed its marker. New --no-sweep flag skips the stale-marker pass; both setup call sites use it (the synthetic --session-id did not prevent the sweep). Surfaced by the Codex adversarial pass. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(hooks): partial upgrades fail closed for freeze and fall back for careful A hook script and its sourced helper can be copied at different times. With an older careful/bin/hook-extract.sh that lacks gstack_hook_state_root: - check-freeze.sh now emits a deny ("fail closed, re-run ./setup or /unfreeze") instead of dying under set -e with no decision JSON. - check-careful.sh falls back to ${GSTACK_HOME:-$HOME/.gstack} so project rules under the plain chain still load and a decision is always emitted (a warn hook must never break on a stale helper). gstack_hook_state_root prints its root without a trailing newline and both callers capture it with a printf-x sentinel, so a GSTACK_HOME ending in a newline round-trips byte-for-byte with the writer's %q form. gstack_hook_log_fire stays on ${GSTACK_HOME:-$HOME/.gstack}/analytics, the same two-step chain every other analytics writer and reader uses, so the usage log remains one file under a plugin install. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(setup): never link over, copy over, or reap a skill gstack does not own (#2119) The relink gate alone left three destructive sites open: - link_claude_skill_dirs runs BEFORE relink on every ./setup and used `ln -snf` (Linux replaces a user's real SKILL.md with a symlink into gstack) or, on Windows, rm -rf + cp followed by a marker that made the user's directory "ours" on the next flip. It and _install_alias_skill_md now consult _claude_entry_is_ours first and skip loudly. - cleanup_prefixed_claude_symlinks kept a bare name-match deletion and a `*gstack*` substring match. Symlink arms use anchored `gstack/` segment patterns; the Windows real-file arm proves provenance (marker, byte-identity with our source, or the full two-line gen-skill-docs banner within the first 40 lines, never a one-line substring another generator could emit). cleanup_old_claude_symlinks uses the same banner rule. - gstack-relink's fast path judged absolute targets before canonicalizing, so `/x/gstack/../foreign/SKILL.md` counted as ours; dot-segment targets now canonicalize first. Its banner rule matches setup's. The `.gstack-owned` marker records the owning payload's realpath. Entries skipped by setup or relink are listed in the final setup summary. Chromium bootstrap refinements from the pre-landing review: an INT/TERM trap kills the installer's process tree; the Windows npm chain no longer masks an install failure; GSTACK_SKIP_PLAYWRIGHT=1 is reported as a choice rather than a failure and sends no telemetry; the timeout knob is normalized (0, 000, non-numeric, or more than nine digits fall back to the 600s default instead of killing on the first poll or never killing). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: README Chromium note outside the CLAUDE.md fence; report banner stripped; deferrals name the four gate sites - README: the Chromium troubleshooting paragraph sat inside the CLAUDE.md snippet code fence, so copy-paste put it into users' CLAUDE.md. Moved to the troubleshooting list. - docs/designs/fork-port-residual-2026-09/REPORT.md: the scratch-run preamble banner is gone; SHAS.md re-hashed. - TODOS: the ownership-gate deferral names the four sites and the marker-path idea for the fork-with-banner residual. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(todos): the bootstrap block coverage gap is pinned except the quarantine helper Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(setup,relink): ownership proof has two strengths; weak proof never deletes a directory or discards a differing file The first #2119 gate treated a byte-identical or banner-bearing real-file SKILL.md as full ownership, so a prefix flip could rm -rf a user's directory (their own qa skill started from a gstack SKILL.md, plus my-templates/) and the link pass could replace their customized file with a symlink. Two strengths now: - STRONG: the .gstack-owned marker (we created the directory), or a directory holding nothing but symlinks and the marker (deleting it loses no data). Only strong proof removes a directory whole. - WEAK: byte-identity with our source or the two-line gen-skill-docs banner on a real file. Weak proof covers that SKILL.md and our runtime-asset links only; a differing file is moved to ${GSTACK_HOME:-~/.gstack}/backups/skills/<ts>/<skill>/ before we link over it, and setup/relink print one summary line naming what moved. The marker is written on every platform now (path-independent proof for Windows copies and for checkouts whose path carries no gstack segment), but only for a directory gstack creates: a directory we merely link into (unclaimed, or a legacy install) never becomes deletable whole. A directory with no SKILL.md at all is unclaimed: the link pass may add our file, the cleanup pass has nothing to remove. Also from the review passes: the banner check reads 8192 bytes, not 40 lines (investigate, office-hours, plan-ceo-review and design-consultation carry the banner past line 40 and were left "foreign" on pre-marker Windows installs); a link into a checkout named without a gstack segment (git worktree add ../gstack-<branch>) is ours when that tree carries setup + VERSION + bin/; relink's fast path is gone so both files canonicalize before judging; relink's root alias (_gstack-command) is gated and stamped like every other entry; relink reports the bare entry name with setup's wording and setup dedupes when forwarding (_run_relink_quiet); the summary names the browser skills as examples. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(setup): Chromium-install lock reclaim is atomic and pid-validated; abandoned locks expire; the tree kill walks /proc without pgrep - A pid file holding "", "-1" or "0" counted as a live holder (kill -0 -1 signals every process and succeeds), locking Chromium out for good. A pid must be a positive integer; anything else is stale. - Two setups judging the same lock stale raced on rm -rf + mkdir and the loser deleted the winner's fresh lock. The stale dir is renamed first (atomic), so exactly one reclaims. - A lock dir with no pid file (killed between mkdir and echo) was never reclaimed; it now expires once older than the install bound. - _kill_tree needed pgrep; debian-slim and git-bash ship none, so the bound killed only the wrapper subshell and the installer kept running. Without pgrep the children are found by walking /proc/*/stat. - The timeout knob is normalized in one place with one comment; the trap's exit 130 is the only exit the block may contain. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(freeze): an unexpected non-zero death denies via an EXIT backstop instead of exiting with no decision set -e plus a failing pipeline (a tool on PATH exiting non-zero, a deleted cwd) ended the deny-tier hook with no JSON, which Claude Code treats as non-blocking: the edit outside the boundary proceeded. The EXIT trap now prints a deny for any non-zero exit that happens before a decision was written; every deliberate output sets _FREEZE_DECIDED first so a late failure never prints a second object. Tests also pin careful's state-root precedence (GSTACK_HOME over CLAUDE_PLUGIN_DATA, plugin data when CLAUDE_PLUGIN_ROOT names gstack) and the specific "out of date" deny for a helper without gstack_hook_state_root. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * refactor(telemetry): guard the stale-marker sweep with an if, not a break inside the loop Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(todos): the ownership gate lives in six sites, and the cleanup arms inline their own chain Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test: the two remaining linker harnesses extract the ownership helpers; the marker is the one allowed dotfile setup-claude-skill-assets and user-render-out-dir-install slice link_claude_skill_dirs out of setup without the helpers it now calls, so the extracted function died with "command not found" (or, inside an if, degraded into "foreign, skipped"). Both harnesses now carry the full helper set and the globals. The hidden-files census allows .gstack-owned, which the linker writes for directories it creates rather than copying from the skill source. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(setup,relink): weak proof never costs the user a file — assets, flips, failed backups, foreign dir links, alias markers Third review cycle on the ownership model, every item reproduced against a fixture before the fix: - Runtime assets (sections/, templates/, checklist.md, ...) were refreshed with rm -rf regardless of who owned the directory, so an unclaimed or weakly-owned directory lost the user's same-named real files. Real assets are now replaced only in a directory gstack created or strongly owns (marker, or SKILL.md symlink into gstack), plus the legacy Windows real-copy shape; elsewhere they are kept and reported. Symlinks are never content and are always refreshed. - The prefix-flip cleanup deleted a customized banner-bearing SKILL.md that the link pass would have backed up. Both cleanups now compare the file against the source (raw, or with its name: line rewritten to the entry name, which is how alias and prefixed copies legitimately differ) and move a differing file to the backup root. - A failed backup (unwritable root) returned success and the caller linked over the file anyway. It now fails, and the entry is left untouched and reported. - A foreign DIRECTORY symlink whose target had no SKILL.md fell through to the "unclaimed directory" rule and was replaced by a real directory. A symlink that does not resolve into gstack is foreign, full stop. - The alias installers stamped .gstack-owned into pre-existing directories; they now follow the same created-or-already-marked rule. - A directory counts as "only links" only when every link resolves into gstack: a user's own symlink makes it mixed, so their link survives. - The gstack-tree heuristic requires bin/gstack-relink, not just a VERSION file, a setup script and a bin/ directory. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(setup): lock reclaim hands a fresh lock back; a live holder past the bound is stale; /proc walk strips through the last paren - Reclaim renamed the lock by path after judging it stale, so a second setup that had already reclaimed and re-created it lost its fresh lock and two installers ran. After the rename the moved directory's pid is re-read: a new live holder, or a fresh lock whose pid is not written yet, is moved straight back. - A pid file whose process is alive but whose lock is older than the install bound is stale too (the holder is past its own deadline, or the pid was recycled to an unrelated long-lived process); it was locked forever. - The /proc fallback stripped the comm field to the FIRST ") ", so a comm containing ") " hid a child from the kill. proc(5) says the last paren. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(freeze): mark the decision written after the helper prints, not before If gstack_hook_decision ever failed between the flag and its output the backstop would have stayed silent; setting the flag after the print keeps the deny backstop armed until a decision is actually on stdout. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * chore: bump version and changelog (v1.80.0.0) Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: update project documentation for v1.80.0.0 README troubleshooting + manual uninstall cover the skill ownership gate (.gstack-owned marker, ~/.gstack/backups/skills/<ts>/, foreign same-name skills left untouched). CLAUDE.md and CONTRIBUTING carry the ownership and best-effort Chromium bootstrap invariants for people editing setup and gstack-relink. PROJECT_STRUCTURE gains careful/, freeze/, guard/, unfreeze/, gstack-upgrade/, gstack-relink, and the setup/relink/hook test files. TESTING_INTERNALS documents the anchor-sliced setup harness convention. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(setup): the final summary reports customized SKILL.md files moved to the backup root The linker moved a weakly-proven, customized SKILL.md aside before linking over it but never said so; only relink printed a "Moved N" line, and by the time relink runs the file is already a symlink. The summary now names each moved file and where it went, next to the foreign-entry report. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * test: run assembled setup harness scripts from a temp file, not `bash -c` argv (Windows MSYS2 8 KB truncation) windows-free-tests (run 33907177851) failed in test/setup-alias-name-uniqueness.test.ts with bash: -c: line 178: unexpected EOF while looking for matching `' The harness slices functions out of `setup` and passed the joined script as one `bash -c` argv element. The ownership gate grew that script from 6.7 KB to 15.7 KB, and on Windows bash is an MSYS2 program: when its parent is a non-MSYS process (bun), msys-2.0.dll's build_argv() runs any argument containing `?*["'(){}` through globify()/glob(), which copies the pattern into a fixed `Char patbuf[8192]` and silently stops after 8192 - MB_CUR_MAX (8186 chars under C.UTF-8); GLOB_NOCHECK then returns the truncated text as the argument. Character 8186 lands inside the single-quoted sed token on line 178. Rebuilding the exact script with CI path shapes and cutting it at 8186-8190 characters reproduces the identical message locally; cmd.exe's 8191-UTF-16 cap and CreateProcess's 32767 do not fit the evidence. Fix: test/helpers/bash-script.ts writes the script to a temp file and runs `bash <path>` — a short glob-free argument that never enters globify. Every setup harness that assembled a script for `bash -c` (11 files, 22 sites) uses it; timeouts and env are preserved verbatim, spawn/timeout errors are appended to stderr, temp cleanup is best-effort. `spawnSync('bash', [<Windows absolute path>])` already passes on windows-latest in setup-help, uninstall-windows-copies and the migration tests. The Windows-curated list is byte-identical before and after. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs(test-free-shards): the rerun-refresh harness spawns bash <tempfile> via test/helpers/bash-script.ts, not bash -c Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>

capy-ai · 2026-10-03T20:50:22Z

Thanks for this, @smblight. The fix is now on main: gstack-relink only removes entries it can prove are its own and reports foreign ones instead (_cleanup_skill_entry in bin/gstack-relink) (fixed in v1.80.0.0, #2802). Closing as superseded; if you still see the problem on the latest gstack, please open an issue with ./setup --status output.

* docs(designs): add fix wave 2026-10-15 plan (revision 3, approved) Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(cso): invoke docker as argv0 docker so OrbStack's multicall binary dispatches executable() returns the canonical path, and OrbStack installs docker as a symlink to docker-tools, which dispatches on argv[0] and exits 127 with 'unsupported argv0 "docker-tools"'. Every Docker call failed, so doctor reported local-docker-isolation and every scanner missing and setup could not preload the qualified images. runProcess takes an argv0 option; docker.ts routes every Docker call through runDocker, which passes 'docker'. The native watchdog's execve calls pass "docker" as argv[0] too, so its container cleanup works on the same installs. The executed file is still the verified canonical path. Fixes #3187 * test(cso): cover Docker and watchdog invocation through a multicall binary A compiled fake that refuses any argv[0] but docker stands in for OrbStack's docker-tools. Both behavior tests fail on the previous code. Refs #3187 * fix(cso): bound the argv0 test's socket helper and probe images through OrbStack's multicall docker (#3187) Follow-up to #3188 by Bryan Stone (@aegixx): - the python3 spawnSync that binds the fake daemon socket gets a 30 s timeout; without it test/spawnsync-timeout-tripwire.test.ts fails. - reviewer test: dockerExactImagePresent, a production probe, admits an image when the endpoint's canonical executable is a multicall binary that refuses any argv0 other than "docker". It fails on 47d639a (returns false) and passes with #3188. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(autoplan): own the conversation after a Claude Code 2.1.300 compaction Claude Code 2.1.300 keeps a compaction's last records in place and lists them in compactMetadata.preservedMessages. The segment's tail, which is also the boundary's logicalParentUuid, is written after the boundary under the compact summary, so the parent links form a cycle that the owned causal order never reaches. Every record after the compaction was dropped, and the publication guard denied each later phase entry with close_incomplete. Such a boundary now continues from the last preserved record that is a node of the file and not its own descendant. Boundaries without that metadata, with a foreign preserved uuid, or with nothing kept in place still supply no ownership. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(autoplan): report a compaction-explained unreachable component as unrecognized_shape (#3194) Follow-up to #3196 by vilano93. After the ownership walk, an owned node the walk never reached was silently dropped, and the phase guard answered the next phase entry with close_incomplete, which the user cannot satisfy. When the unreachable node's ancestry ends in a cycle through a compact boundary's logical parent, ownedCausalOrder now returns unrecognized_shape:compaction_unreachable, the guard's existing unverified disposition (allow with a visible warning and a guard-log row). Orphans whose ancestor is missing (not flushed yet) and other roots keep today's behaviour, so the fail-open surface does not widen beyond compaction. Each node is walked once. Gate-integrity edit: a close_incomplete denial becomes an unverified allow for that shape only. Negative controls kept: the existing guard, hook, guard-reasons and captured-fixture tests still deny (356 pass), and a new case with the boundary not yet flushed still denies close_incomplete. Intentional pin changes in #3196's own test file: the three "fails closed" cases (tail-only segment, missing preserved metadata, foreign preserved uuid) and the "without compactMetadata" case now expect unrecognized_shape:compaction_unreachable instead of close_incomplete or a silently cut transcript. Reviewer tests: three compactions in one session stay owned and pass the next phase entry; a 50k-record history with three compactions is decided in ~300 ms (budget 1000 ms), so descends needs no memo. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * feat(lib): one echo sanitizer for external strings, with a Bash twin lib/sanitize-echo.ts and bin/gstack-sanitize-echo.sh flatten CR/LF/TAB to spaces, remove every other ASCII control byte (ESC included) and DEL, collapse runs of spaces, and cap the result at 200 bytes of valid UTF-8 with no leading or trailing space. Every external string gstack echoes into a message, a log line or a key=value state file goes through it (fix wave 2026-10-15, plan rev 3 DX F8). test/sanitize-echo.test.ts runs both twins on one table under bash, bash --posix and zsh, including a "\nstages=" injection, ESC sequences and UTF-8 characters cut by the cap. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(bun-version): judge the Bun floor under zsh and hold on an unreadable version (#3195) Reported by mochafreddo. _gstack_bun_below word-split $_gb_core, which zsh does not do: `[ -ne ]` errored and every error path read as "not below", so /gstack-upgrade Step 4 accepted Bun 1.3.2 in a zsh tool shell. - _gstack_bun_below copies the release's parsed fields into quoted positional parameters and compares with $((10#...)); no new _gb_* globals. It returns 2 when either side cannot be parsed. - gstack_bun_status prints malformed for an unparseable version or floor (never ok); gstack_bun_incoming_hold holds on it with bun-version-unreadable: ... (BUN_VERSION_UNREADABLE), the bun path and its output passed through gstack_sanitize_echo. setup's own malformed warning is unchanged. - /gstack-upgrade Step 4 runs the check through `bash -c` and stops on BUN_VERSION_UNREADABLE with a reinstall fix (never "bun upgrade"). - New result code BUN_VERSION_UNREADABLE with its troubleshooting entry; bin/gstack-doctor-components.sh regenerated from the table. test/bun-version-shells.test.ts: one version table (1.3.2, 1.3.3-canary.1, 1.3.3, 1.3.14, 1.4.2, 1.10.0, 01.04.02, 2.0.0, garbage) drives bash, bash --posix, zsh and the TypeScript twin's below(); `zsh -c '. bin/gstack-bun-version.sh; gstack_bun_status 1.3.2'` printed ok on 47d639a and prints too-old now. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * style(cso): format #3188's runDocker call so format:cso:check passes (#3187) Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(cso): keep scanner JSON reports parseable after redaction (#3185) Reported in #3185. The scanner path splices redactions into raw JSON, and redactFindingSpans replaced a bare 10+ digit number ("max_memory_bytes":1145427776, an epoch) with an unquoted marker, so JSON.parse failed and every non-trivial Semgrep run was INVALID_OUTPUT. - lib/redact-engine.ts: redactJsonFindingSpans, a string- and escape-aware lexical tokenizer over one or more top-level values (NDJSON included). A span inside a number replaces that whole token (-, fraction, exponent) with the quoted marker, number by number; a span inside a string keeps the in-string marker, widened to whole escapes; a span touching several tokens, whitespace, a literal or a structural character returns null (withhold). Non-JSON text gets the plain splice. redactFindingSpans is unchanged for every other caller. - The scan operation's declared format rides the real capture path: scanner-executor (scan stdout, or the report file read for outputPath plans) -> DockerGroup.execCapture -> runProcess -> spliceRedaction, which redacts the concatenated stdout once and maps each interleaved run onto it. Version probes and stderr stay plain; marker-only withholding and the cross-stream views check are kept, and the output is a fixpoint of that check. Behavior change: a redacted number in a scanner report is now the string "<REDACTED-...>" instead of an unquoted marker; non-JSON streams keep the unquoted form (test/cso-eval.test.ts unchanged). Intentional pin change: test/cso-scanner-release.test.ts pinned the report read as capture(['/bin/cat', plan.outputPath]); it now pins capture(['/bin/cat', plan.outputPath], plan.format), so the read also carries the declared JSON format (stricter, not weaker). Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(browse): recover when the last tab is closed outside the CLI Closing the last tab outside browse (for example, closing the headed Chromium window) left the daemon wedged: the page 'close' handler removed the tab and set activeTabId to 0, and executeCommand called getActiveSession() first, so every later command (goto, status, even stop) failed with "No active page" until the daemon PID was killed by hand. closeTab() already opens a blank tab when the last tab closes; the external close path never did. Add BrowserManager.ensureActiveTab(), which reselects a remaining tab or opens one blank tab (concurrent callers share one recovery), and call it before resolving the active session in executeCommand. Fixes #3167 * fix(browse): status and stop answer after an external close; recovery says what it did (#3167) Follow-up to #3179 by aftabkh4n, which reopens a tab on demand. - BrowserManager.ensureCommandTab runs before every command: status, stop and restart never open a tab, so a daemon whose browser or context is gone can still report and be stopped; any other command gets an active tab. A failed recovery is BROWSE_TAB_UNRECOVERABLE carrying the restart command (cause passed through sanitizeEcho), and a command that ran on a newly opened tab prints a one-line warning first. - server.ts reads the session inside the read and write branches instead of before dispatch (2223 lines, cap 2224) and exposes browserManager and handleCommandInternal on __testInternals__ for the dispatch test. - meta-commands.ts: handleMetaCommand no longer reads the active session before its switch (only snapshot and resume used it), and status prints getCurrentUrl() so it works with zero tabs. This file is outside the lane's listed ownership; no other lane or #3190 touches browse/. - New result code BROWSE_TAB_UNRECOVERABLE and troubleshooting entries for it and for the old "No active page" wedge. Reviewer test browse/test/tab-external-close-dispatch.test.ts drives the real dispatch in a child process: status, text, goto and stop after an external close, and the closed-context case. On 47d639a (with only the test seam added) all five fail with "No active page". Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * docs(troubleshooting): /cso INVALID_OUTPUT on Semgrep reports and OrbStack's argv0 refusal (#3185, #3187) Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(session-update): name the reinstall fix when an unreadable Bun holds the auto-update (#3195) Item 11 makes every caller of gstack_bun_incoming_hold treat a Bun version it cannot read as a hold (bun-version-unreadable, BUN_VERSION_UNREADABLE). The session-start banner only knew bun-too-old, so the new reason fell through to "git pull did not finish ... gstack is not updating" with a pull-and-setup fix that does not help. - bin/gstack-session-update: a bun-version-unreadable banner case with the reinstall fix and the troubleshooting anchor; the comment that said a malformed version passes is corrected. Intentional pin change: test/session-update-stages.test.ts "supported or unparseable Bun (bun-dev (local build)) proceeds: setup decides" is split. 1.3.14 still proceeds; bun-dev (local build) now holds with BUN_VERSION_UNREADABLE, leaves the checkout and setup untouched, and the banner names the reinstall fix. The fixture installs bin/gstack-sanitize-echo.sh beside the floor helper, as a real install of this release does. The new case fails on 47d639a. Ownership exception granted by the coordinator for Lane A (bin/gstack-session-update is Lane B's file; PR 1b stacks on 1a). Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(session-update): recover a conflicting autostash by its unmerged files The auto-updater fast-forwards with `merge --ff-only --autostash`. When the carried-over local edits conflict with the incoming revision, git 2.56 still exits 0 from that merge, pops the edits with conflict markers into the live checkout, and keeps the stash entry. The recovery only ran on a non-zero exit with "autostash" in stderr, so on git 2.56 it never ran: the updater logged UPDATED and ran setup over a half-merged tree, in the directory Claude Code runs hooks from. When it did run, it had two more problems: - `git checkout -- .` refuses unmerged paths ("error: path 'f' is unmerged", exit 1), so it left the markers in place anyway. - `git stash drop` dropped stash@{0}, whatever that was. refs/stash is shared with every worktree of the repository, and when refs/stash.lock is held git cannot store the autostash at all, so the top entry can be someone else's. Now the merge is judged by `git ls-files -u`, whatever its exit code. On unmerged files after the fast-forward, autostash_recover finds the autostash commit by the id git prints ("cannot store <id>" first, then "Created autostash: <id>", with the merge run under LC_ALL=C and core.abbrev=40). A moved refs/stash is only the fallback. When that id is not a stash entry, it is anchored under refs/gstack-autostash/<UTC>. The tree is reset to the fast-forwarded revision, which the hook check already passed, and the stash is kept. The log line is AUTOSTASH_CONFLICT_RECOVERED tree_reset=1 kept_stash=<id> kept_ref=<ref>. The update then continues, so the regenerable patches are re-rendered and setup runs as for any other move. If the commit cannot be found, nothing is reset: the markers stay for a person, the run logs PULL_FAILED, and setup does not run. Files that are already unmerged before the update, from someone's own merge, rebase or stash pop, now hold the update with PULL_FAILED "unmerged files ...". Without that check, the recovery would take them for its own and reset them away. core.abbrev=40, not "no": "no" is accepted from git 2.31.0 (its release notes), and `merge --autostash` exists from 2.27.0, so "no" would fail every update on git 2.27-2.30. Files: - bin/gstack-session-update: autostash_recover, the unmerged-files check before the merge, the C-locale merge with its stdout kept for the id, and removal of the old grep-and-drop block. - test/session-update-autostash.test.ts: 7 cases in a new describe block. A conflicting pop leaves no markers, keeps the edits and still runs setup. A user's own stash entry survives. A held refs/stash.lock gets the edits anchored. With a git whose merge prints nothing, a moved refs/stash still finds the edits; with the lock held as well, nothing is reset. Pre-existing unmerged files hold the checkout. A non-conflicting edit rides over the update (control). Tests, on upstream 15ebd85cd: - 5 of the 7 new cases fail against the previous session-update; the unmerged-files guard and the control pass on both. - Two mutants are each caught by one new case: dropping the refs/stash fallback, and resetting when the edits cannot be found. - session-update-autostash, session-update-stages, session-update-hook-hold and team-mode pass 63/0 with `--timeout 60000`. At bun's 5 s default under heavy load (one reading: load average 169), the three shared files timed out 8 tests on this branch and 17 with the previous script. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(session-update): trust only git's autostash id; owe setup on a stop An independent review of the autostash recovery (Codex gpt-6-astra, high effort, verdict BLOCK high=1 med=2) found three defects on its rare paths. All three are fixed here, each with a case that failed first. - [high] The refs/stash fallback could erase local edits. When git's messages were unavailable, recovery took any change to refs/stash as its own autostash. refs/stash is shared with every worktree: if a sibling pushed a stash while refs/stash.lock kept git from storing this one, recovery took the sibling's entry and reset the checkout, erasing edits nothing held. Now only git's own printed id counts. A missing id resets nothing: the markers stay, the run logs PULL_FAILED. Recovery needs git's messages, so when the temp file for them cannot be created the update is held before the merge (HELD temp-file-unavailable), not merged blind. - [med] A stop after the checkout moved lost the setup it owed. The failure recorded only the pull reason. Once the person resolved the conflict, the next check saw an unchanged HEAD and no pending stage, logged UP_TO_DATE, and never set up the new revision. Now a failure after HEAD moved records `setup` as a pending stage, retried at once. The unmerged-files check holds it until the conflict is resolved, and the pull reason is the stage's reason, so the session-start line says what to resolve. - [med] An unreadable index read as "no conflicts". Both `git ls-files -u` checks discarded the exit status, so a failed read after a conflicting pop (which git exits 0 for) let setup run over the markers. Now a failed read stops the update with PULL_FAILED "cannot read the index", before the merge or after it. Files: - bin/gstack-session-update: autostash_recover drops the refs/stash fallback (and STASH_BEFORE). The temp-file hold. The ls-files exit status checked at both points. The pending setup stage on a failure after HEAD moved. - test/session-update-autostash.test.ts: a shim(fx, name, tool, body) helper; the fallback case now expects a refusal; the refusal case runs on through resolution to setup; three new cases (unreadable index before and after the merge, no temp file for git's messages). Tests, on upstream 15ebd85cd: - The 5 changed or new cases failed on the previous commit, each on its defect: refs/stash trusted and recovered; UP_TO_DATE with no setup after resolution; UPDATED over an unreadable index, before and after the merge; a blind merge with no temp file. - Against upstream's own session-update, 8 of the block's 10 cases fail. - session-update-autostash, session-update-stages, session-update-hook-hold and team-mode pass 66/0 with `--timeout 90000`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(session-update): reap heartbeat and its sleeper on exit The lock heartbeat subshell left its sleep 300 child orphaned when the updater exited, so heartbeats accumulated across sessions. Track and reap the heartbeat job (with a job-table fallback for signals between fork and $!), give the subshell its own exit trap that kills and waits its sleeper, and map HUP/INT/TERM to exits so the EXIT trap always runs. Adds a fixture-driven regression test. * test(session-update): repin the lock trap and heartbeat to #3191's cleanup shape Intentional pin change: test/session-update-autostash.test.ts 'reclaim is TOCTOU-safe' and 'EXIT trap is ownership-checked' pinned the one-line EXIT trap and the 'while :; do sleep 300; ...' loop that #3191 (Jess Sullivan) replaces with cleanup_session_update and a 'sleep 300 & wait' heartbeat. The pins still assert the ownership-checked rm -rf, the EXIT trap, MYPID, and that the heartbeat is killed. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(session-update): move installs only through gstack-ff-update; extract hooks without tar (#3184) Item 2 (#3189, #3191 adopted in the previous commits) and item 3 of the fix-wave plan. bin/gstack-ff-update <dir> <rev> is now the only code that moves an install's tree. Inside an install-scoped lock (absolute git common dir, the updater's TTL and mv-aside reap, a heartbeat reaped on exit) it captures the working tree and the staged state through private indexes, carries edits that merge cleanly (as an autostash pop would), lets the regenerable SKILL.md/sections footprint take the target when it conflicts, and shelves any other conflicting edit, staged change or unmerged file into refs/gstack/rescue/<oid> (first parent the pre-update HEAD, second the staged state; compare-and-create; gstack rescue identity). The move is a two-way read-tree on the private index, so a late edit or an untracked file in the way refuses with autostash-unrecoverable and changes nothing. It sources nothing so the held-install recovery can fetch it from the new revision. gstack-session-update calls it instead of merge --autostash, holds a checkout with unmerged files (unmerged-files:), and names shelved edits at session start at most once a day with inspect, export-the-delta and delete commands. The incoming revision is extracted for the hook check through a private index and checkout-index with core.symlinks=false, never tar (MSYS tar cannot create connect-chrome before its target), and the held reason carries the failing command's flattened, control-free stderr. Held lines print before the stage line, one case per reason with its anchor, every path shell-quoted, no setup fix while unmerged files exist. docs/troubleshooting.md gains the held-install recovery forms (Git Bash, PowerShell 5.1, trial and go-back) and entries for each new line. design: kept_ref is refs/gstack/rescue/<oid>, refs/stash is never touched, the quiet-merge cases become a pre-existing-ref refusal and its recovery, pre-existing unmerged files are a HELD unmerged-files, and the git shim pins the real binary through git --exec-path. Intentional pin changes in existing tests: - test/session-update-stages.test.ts: printed paths are shell-quoted; the bun-too-old fix runs gstack-ff-update instead of git pull. - test/session-update-hook-hold.test.ts: the order pin looks for 'bash "$FF_UPDATE"' instead of 'merge --ff-only'; the hook-check-unavailable fix no longer recommends git pull --autostash; installedUpdater copies gstack-ff-update beside the updater. Reported by wengweiling (#3184). Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(gstack-upgrade): Step 4 fast-forwards through gstack-ff-update (#3189) Item 2 of the fix-wave plan, kept in its own commit so PR 1b can be rebased onto PR 1a (which edits only Step 4's Bun floor-check line). Step 4's `git pull --ff-only --autostash` had the same hole the auto-updater had: a conflicting autostash exits 0 and leaves conflict markers in the install, and the skill printed FF_OK. It now runs bin/gstack-ff-update . origin/main after the fetch and the floor check: exit 0 runs setup (a rescued line is relayed with its inspect, export and delete commands), exit 4 (not a fast-forward) is the only way into the gated reset fallback, and any other refusal stops with nothing changed. The footprint discard moves to the reset fallback, ahead of its stash, where the warning text already promised it. Intentional pin changes: - test/upgrade-template-pins.test.ts: the ff-before-reset pin looks for 'bash bin/gstack-ff-update . origin/main'. - test/gstack-upgrade-fresh-shell.test.ts: the C9 fence marker is 'bash bin/gstack-ff-update'; the gstack-like fixture ships the bin. - test/upgrade-setup-recovery.test.ts: the git-path fixtures ship gstack-ff-update (a stub where git itself is a stub). Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(setup.ps1): run under Windows PowerShell 5.1's legacy argument passing (#3130) Item 4 of the fix-wave plan. Windows PowerShell 5.1 strips the double quotes inside native arguments, so the bash -c script setup.ps1 handed Git Bash arrived broken ("unexpected EOF while looking for matching"). The script now holds no double quote: `set -f; IFS=; mapfile -d '' -t argv < $1; rm -f -- $1; exec ./setup ${argv[@]}` (empty IFS and no globbing keep $1 and each argv entry whole). That form drops an empty argument, so setup.ps1 refuses one before anything runs (SETUP_PS1_EMPTY_ARGUMENT, with its troubleshooting entry). test/setup-ps1.test.ts runs the adversarial arguments under legacy passing (pwsh with $PSNativeCommandArgumentPassing = 'Legacy', and powershell.exe itself on Windows) with a space in TMPDIR, plus the empty-argument refusal. Intentional pin change: the pinned bash -c line in "passes arguments NUL-separated through a private file to a constant bash script" now names the quote-free script and asserts it holds no double quote. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(setup): register hooks at the $HOME path when CLAUDE_CONFIG_DIR links back to it A per-session CLAUDE_CONFIG_DIR whose skills symlink to ~/.claude/skills passed the split-brain guard, so its temporary path was written into the global settings.json and the hooks broke once the session directory was removed. Fall back to $HOME/.claude/skills/gstack whenever both spellings resolve to the same tree. Fixes #3180 * fix(setup): one sourced helper picks the hook root for setup and gstack-memorable (#3180) bin/gstack-memorable carried a verbatim copy of setup's old canonical-root block, so `gstack-memorable enable` under a per-session CLAUDE_CONFIG_DIR still baked the session path into settings.json after #3181 fixed setup. The choice now lives in bin/gstack-claude-root.sh (gstack_canonical_claude_root), sourced by both. Intentional test changes: - test/setup-hook-canonical-paths.test.ts: #3181's source-slicing block test is rewritten to source the helper (with a spawnSync timeout, which the sliced version lacked and the tripwire flags); the "honors CLAUDE_CONFIG_DIR" pin moves from setup to the helper, and a new pin requires both callers to source it. Adds a no-$HOME-install case. - test/setup-hook-syntax-gate.test.ts: the hook-section slice starts at the new assignment and the harness sources the helper. - test/setup-claude-code-migration.test.ts, test/team-mode.test.ts: the partial-checkout fixtures copy the new helper setup sources. Reviewer test: gstack-memorable enable under a per-session config dir that links back to ~/.claude registers the $HOME path (fails on main). Builds on #3181 by NetrioGit. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(setup): remove 1.31-era unprefixed Cursor skill folders (#3133) A 1.31 setup run from a checkout under ~/.cursor/skills linked unprefixed <skill>/ folders there, each holding a SKILL.md symlink into the checkout. Current setup links gstack-<skill>/ folders, and the retired-skill prune only looks at gstack-* names, so the old folders stayed: Cursor loaded autoplan, review and the rest twice, or kept dangling links once the checkout moved. Run the Claude flat-name cleanup on ~/.cursor/skills as well. Cursor installs only gstack-* names, so no prefix gate is needed, and the helper removes only entries proven to link into gstack (#2119), so user-owned folders stay. It runs after linking, so a run that fails before the new links exist keeps the old folders. Reported by @andrewkjankowski in #3084. Fixes #3133 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(setup): name the skills dir in the flat-name cleanup line (#3133) `./setup --host cursor` now runs the flat-name cleanup on ~/.cursor/skills as well as ~/.claude/skills, so the "cleaned up old entries" line says which directory the folders were removed from. Reviewer test for #3152 (szsunyuan): a real dir whose SKILL.md links into gstack loses only that link and keeps the user's file; SKILL.md links into a sibling repo named gstack-fork, a relative link, and a dangling link outside any gstack checkout are all kept; the printed line names the removed folders and the Cursor skills dir. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(setup): install Chromium with `bun x`, and name exit 127 for what it is (#3131) A Bun installed with winget ships no `bunx`, so setup's `bunx playwright install chromium` exited 127 and was reported as "offline, proxy, or blocked download?". setup now runs `bun_cmd x playwright install chromium` through its existing bun resolver ($BUN_CMD), and bin/gstack-browser-ensure runs the bun it found on PATH with `x`. Exit 127 gets its own text naming the resolved bun, Bun from bun.sh, and the skip commands for Git Bash and PowerShell; other codes keep the network hint. New troubleshooting entry: #chromium-install-exit-127. Intentional test changes: - test/setup-playwright-best-effort.test.ts: the installer stub is now a `bun_cmd()` stub (was `bunx()`), its mark renamed bun-x-called and now records the args; the block under test calls bun_cmd. New winget-shaped cases (bun on PATH, no bunx anywhere) run setup's real bun_cmd. - test/gstack-browser-ensure.test.ts: the fixture is winget-shaped (the `bun` stub handles `x`, no `bunx` on PATH); the exit-7 pin now reads `<stub>/bun x playwright install chromium exited 7 (...)`. --help in gstack-browser-ensure prints the comment header only (3,24p). Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * ci(windows): prove setup.ps1 on PowerShell 5.1 and the held-install recovery natively (#3130, #3184) windows-setup job: - setup.ps1 joins the path filter (with bin/gstack-ff-update, bin/gstack-claude-root.sh, bin/gstack-browser-ensure, docs/troubleshooting.md and test/setup-ps1.test.ts). - powershell.exe must be Windows PowerShell 5; test/setup-ps1.test.ts runs with a space in TEMP and must report exactly 4 pass, 0 fail, 1 skip (the Linux-only missing-prerequisite case). - A copy of the built checkout under a path with a space installs through `powershell.exe -File setup.ps1 --host codex`. held-install-journey job (new, parallel): - origin's main is this PR's tree on top of the v1.91.101.0 tree (47d639abf); fix-branch adds one file. - A prefix-mode v1.91.101.0 install at the runner's ~/.claude path in three states (clean, dirty-conflicting, already-unmerged), with auto_upgrade=true and the throttle cleared: the old updater must log `HELD hook-check-unavailable`; the PowerShell recovery form, read verbatim from docs/troubleshooting.md and run under powershell.exe, must reach main with every local edit (only those) in one rescue ref. The dirty state runs it with its .\setup.ps1; the others replace that step with a marker. - The trial and go-back forms move the install to fix-branch (detached) and back to main. - Only then a later release whose symlink sorts before its target is pushed, and the new updater must log UPDATED and reach it. - Both jobs assert the exact list of cases that ran. The journey steps ran locally on Linux with pwsh in Legacy argument mode as powershell.exe, a git exec-path whose ../../../bin/bash.exe is bash, and a failing tar standing in for MSYS tar (all 9 cases passed); the windows-latest run itself happens on the PR. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * test(ff-update): a killed step-4 run fails the status check instead of the type check Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * ci(windows): the held-install job runs without the bun cache step The cache key line is a secret-scanner false positive on added lines (env.kv); the fixture's own setup installs its packages either way. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * test(fixtures): register #3191's heartbeat fixture as free test/free-fixtures.test.ts failed on the frozen-branch Ubicloud run: test/fixtures/session-update-heartbeat.sh (adopted with #3191) was in no paid touchfile and not in FREE_FIXTURES. Its only consumer is test/session-update-heartbeat.test.ts. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(session-update): leave the bun-version-unreadable banner case to item 11 (PR 1a) PR 1a owns the bun-version-unreadable hold (BUN_VERSION_UNREADABLE), its banner case and its troubleshooting entry; this branch is rebased onto 1a. Drops the case, the docs entry and the banner test this branch had added. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(setup.ps1): resolve Git Bash in the shared order, with GSTACK_BASH as an alias and a BASH_UNAVAILABLE refusal Follows lib/script-invocation.ts (Lane C, PR 2): GSTACK_GIT_BASH is the override and GSTACK_BASH its deprecated alias at the same precedence; when both are set and differ GSTACK_GIT_BASH wins and one warning prints. An override that does not exist is refused, never skipped. Without one: the install git --exec-path belongs to (behind a scoop shim, or a portable Git), the folders around git.exe, %LOCALAPPDATA%\Programs\Git, %ProgramFiles%\Git, and last a bash on PATH whose uname -s reports MSYS; WSL's bash (System32, WindowsApps) is rejected. A miss lists every candidate with its rejection, then the PowerShell user-variable and ~/.claude/settings.json env recipes (BASH_UNAVAILABLE, #bash-unavailable). test/setup-ps1.test.ts gains a 14-row pwsh-on-Linux table with every location injected (override, alias, both set, missing override and alias, scoop shim, per-user, portable and machine-wide Git, MSYS PATH bash, WSL and non-MSYS rejections, missing); 11 rows fail on main. The rows mirror Lane C's table in test/script-invocation.test.ts; they are not wired to it, since that branch is not available here. The Windows job's expected skip count for this file moves from 1 to 15 (the table is Linux-only). Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(setup.ps1): give the empty-argument refusal its result code (SETUP_PS1_EMPTY_ARGUMENT) Adds the row to lib/result-codes.ts (anchor #setup-ps1-empty-argument, which setup.ps1 already prints). bin/gstack-doctor-components.sh is regenerated from the table (generated; resolved by regeneration at merge). Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * ci(windows): silence SC2016 on the PowerShell version probe (the $ is PowerShell's, not bash's) Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * ci(windows-setup): give tar a POSIX path for the spaced checkout MSYS tar reads `D:\a\_temp/...` as host:path (rsh syntax) and fails with 'Cannot open: No such file or directory' before setup.ps1 runs. The copy target now goes through cygpath -u; setup.ps1 still gets the Windows form. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * ci(windows-setup): dereference symlinks when copying the spaced checkout MSYS tar cannot extract connect-chrome, a symlink that precedes its target (the #3184 failure mode), so the copy died before setup.ps1 ran. tar -h stores the target instead. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(windows): one Git Bash resolver for gstack's shebang bins (#3197) Windows has no shebangs, and gstack had three conflicting bash lookups: the hooks fell back to a bare PATH `bash` (often WSL's launcher), the gbrain sync checked three fixed paths, and setup.ps1 walked up from git.exe. lib/script-invocation.ts is now the only TypeScript resolver: GSTACK_GIT_BASH (GSTACK_BASH as a deprecated alias, same precedence, warning when they differ, a missing value refused), bash next to `git --exec-path` (scoop, per-user, portable Git), the known install paths, then a PATH bash only when `uname -s` reports MSYS/MINGW. WSL launchers are rejected unprobed. A miss is BASH_UNAVAILABLE, listing every candidate with its rejection reason. Bun-shebang bins run under Bun (process.execPath, or the PATH bun inside a compiled binary). Hooks' runBin resolves through a state-root cache keyed by git.exe path and mtime, written by temp file plus rename, so the hot path spawns nothing extra; the override is never cached. wtreeFingerprint({cwd, timeoutMs}) returns {tree} | {error, kind} with GIT_OPTIONAL_LOCKS=0 and 40-64 hex ids; the consumers move next. Intentional pin change: test/gbrain-spawn-windows-shell.test.ts expects forward-slashed bash paths (WIN_BASH and the GSTACK_BASH override), the form the shared resolver returns because Bun's spawnSync on Windows returns ENOENT for a backslash exe path containing spaces. The copied-tree adapters in test/timeline-stop-hook-slug.test.ts and test/plan-tune-cathedral.test.ts list the two modules spawn-bin.ts now imports; the new fixture is registered in test/helpers/free-fixtures-data.ts. bin/gstack-doctor-components.sh is regenerated for the new result-code row. Reported by @exGeni. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(windows): fingerprint and gstack bins through the shared invocation (#3197) bin/gstack-wtree was spawned by path in lib/regen.ts, lib/gate-diff/git.ts, lib/restamp.ts and bin/gstack-evidence; gstack-slug in restamp, gate-diff and evidence; gstack-redact in the pregate secrets check; and a bare `bash -c` in regen, the lane selection manifest and gstack-evidence run. On Windows each one failed to launch. All now go through lib/script-invocation.ts, and each fingerprint consumer keeps its fail direction while saying why: - gstack-regen check: incomplete, `cannot fingerprint the working tree (gstack-wtree exited 1: <helper's own repair>)` instead of `(gstack-wtree failed)`; write keeps the registry label as its run id. - gstack-gate-diff: `+nowtree` candidate, with the cause. - gstack-restamp: RESTAMP_CONFLICT carrying the launch or exit detail (Windows printed `()` before). - gstack-evidence: records without wtree (grades STALE) and warns once; SHA-256 repositories now get a 64-hex fingerprint. lib/regen.ts keeps a string-returning wtreeFingerprint(repoRoot) wrapper for lib/pregate/context.ts and lib/pregate/index.ts (files #3190 changes); item 10b migrates them. test/script-invocation-tripwire.test.ts fails on a new by-path or bare-bash spawn under lib/, hosts/ or a Bun bin; five sites outside this change are listed with their owners and may only shrink. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(pregate): keep framework route paths from a selection manifest (#3176) laneFileSet parsed manifest output with `[\w.-]+` path segments, so `app/(shop)/[id]/page.test.ts` came back as `page.test.ts`. The selected test then matched no platform lane, its remote receipt obligation vanished and it fell back to a local run. manifestTestPaths keeps route segments whole (`(group)`, `[id]`, `[...slug]`, `[[lang]]`, `@slot`, `$param`, `+page`), reads every path-shaped token on a line (JSON arrays, quoted, `path:line`, parenthesized), and decides what is a test file with the import graph's own isTestFile, so a test-file rule change there (bats, #3177) reaches manifests without a second regex. A manifest that cannot start is "unknown" (widens), like a non-zero exit. This is the manifest-parser half of #3176 by @vocodestudios; the import-graph half (tsconfig aliases, Next.js route mapping) ships in a separate PR. test/pregate-manifest-paths.test.ts drives the CLI with a bracketed route test in the fixture's Windows-only lane and asserts its requires-remote obligation; it failed on main (requires_remote was []). Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * ci(windows): windows-pregate-e2e drives the #3197 paths natively A windows-latest job (Bun 1.4.2) builds a fixture repository and runs gstack-restamp --dry-run, gstack-regen check and write, gstack-evidence run and gstack-gate-diff from their TypeScript entry points, asserting a real tree fingerprint each time; times a question-log hook cold and warm and checks it cached its Git Bash resolution; and checks that a missing GSTACK_GIT_BASH refuses with BASH_UNAVAILABLE and lists the candidate. The journey runs twice: under the runner's Git for Windows and under a pinned PortableGit 2.56.0.2 (SHA-256 verified), found only through `git --exec-path`. gstack-pregate run joins it with item 10b. The workflow is registered in scripts/test-pr-profile.ts FREE_ONLY_PR_FILES (no paid case reads it), recorded as a non-behavioral HARNESS_VERSION decision in scripts/harness-version.json. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(setup.ps1): resolve Git Bash by the shared fixture table (#3197) test/setup-ps1.test.ts now drives setup.ps1 through every row of test/fixtures/windows-bash-resolution.json, the table that pins lib/script-invocation.ts, instead of a hand-mirrored copy. Two rows failed and are fixed here: - an override and alias that differ only in slash direction no longer print the differ warning; - the root git --exec-path names is also searched for usr\bin\bash.exe (Git for Windows on arm64). Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * test(windows): isolate the no-bash case and launch pregate as the product does (#3197, #3176) windows-free-tests run 38813751242 failed two tests this layer added. Both were fixture defects on a real Windows host, not product defects: - gbrain-spawn-windows-shell "returns null when Windows has no bash" stubbed only `exists`. The resolver's PATH step asks the real Bun.which and found the runner's MSYS bash, which is correct. The case now also stubs `which` and `gitExecPath`, so it really means "no bash anywhere". - pregate-manifest-paths spawned the extensionless bin/gstack-pregate directly. CreateProcess cannot exec a shebang, so nothing ran and stdout was "". It now launches through lib/script-invocation's runScriptSync, gstack's own Windows invocation, so the case runs the manifest lane end to end on Windows instead of being excluded. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * ci(windows): the missing-bash step survives the refusal it expects (#3197) GitHub runs `shell: bash` as `bash -eo pipefail`, and the step's own `set -uo pipefail` does not turn -e off. So when gstack-restamp refused, as the step expects, `OUT=$(...)` aborted the script before `CODE=$?` and before any output was printed: exit 1 after 0.5 s with nothing in the log (PR #3209, job 116729693492). The capture is now `OUT=$(...) && CODE=0 || CODE=$?`. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * test(pregate): the manifest-lane case expects the host's own remote lanes (#3176) Once 8b2f297cc made the case run on Windows, windows-free-tests run 38824886195 (shard 4) showed the expectation itself was Linux-only. pregate owes a lane remotely when its runner platform is not the host's (lib/pregate/workflows.ts). On a Windows host the fixture's Windows lane runs locally, and the Ubuntu `free-tests.yml/unit` lane is the remote obligation; that is the record Windows produced. The case now derives the owed lanes from the host the same way. On Windows it also requires `ran: node --test 'app/(shop)/[id]/page.test.js'`: there the route reaches the local run only through the manifest's whole path. With a cut manifest path (page.test.js) the local set is empty, checked through buildContext({ platform: 'win32' }) + selectLanes. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * ci(windows-setup): expect 31 skipped setup.ps1 cases now that the shared table drives it Layer 2 drives setup.ps1 through the 16 shared rows of test/fixtures/windows-bash-resolution.json; like the 14 existing resolution rows they run under pwsh on Linux and skip on Windows. The case list is still asserted exactly (4 pass, 0 fail, 31 skip). Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * test(ship-measure): give the CLI tests a private HOME (#3162) Every bun run test left ~/.gstack/projects/ship-measure-cli-*/evals and sweep-cli-fake-*/evals in the developer's real home, and the free-suite runner flagged them ("real home changed ... Give the writer a private HOME/GSTACK_HOME"). ship-measure's diagnostic-dir check calls getProjectEvalDir(), which builds the eval dir from os.homedir(), and these two CLI tests passed the real HOME while overriding only the state root. Both now set HOME and USERPROFILE to the test's own state dir. The sweep test also runs on the Windows lane, where os.homedir() reads USERPROFILE. test/ship-measure.test.ts:79 already gives its config test a private HOME the same way. getProjectEvalDir() itself is unchanged: whether eval history should follow GSTACK_HOME is left open in #3162. Fixes #3162 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(ship-measure): prove the sweep CLI never writes under the parent HOME (#3162) Reviewer test for #3163 (adopted from y$un_, forrest.sun527): points the parent HOME at a sentinel with a stub global gstack-slug and asserts no .gstack dir appears there. Fails on 47d639a (the sentinel gets .gstack/projects/leaked-slug/evals); passes with #3163. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * test(redact): isolate fixture git from inherited hooks Fixture git was spawned with the parent environment, so a developer's core.hooksPath ran on the local push and rejected it (#2967). The helper blanks the global and system files and drops GIT_CONFIG_COUNT and GIT_CONFIG_PARAMETERS. A hooksPath set in the fixture repo still runs. * test(redact): blank GIT_CONFIG_GLOBAL with /dev/null on every platform (#2967) Follow-up to #3156 (adopted from Lockyer228): Git for Windows rejects GIT_CONFIG_GLOBAL=NUL (the repo convention is EMPTY_GLOBAL_GIT_CONFIG = '/dev/null' in lib/cso/process.ts), so both fixture helpers use /dev/null everywhere. Reviewer test: a hooksPath in the default global files under HOME/.gitconfig and XDG_CONFIG_HOME/git/config cannot reject the fixture push; it fails with the inherited environment (the 47d639a behavior) and passes with the isolated env. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix: gstack-config compares whole root paths and prints a runnable recovery command - report_root_disagreement compared word-split values, so two variables naming the same directory with a space were reported as disagreeing. Compare each complete value instead. - The privacy-key recovery hint single-quoted the root and left the script path bare; an apostrophe or space made it unrunnable. Quote with printf %q. - On Bash 3.2 (macOS /bin/bash) a failed `.` under set -e exits before the `||` fallback, so a missing gstack-state-root.sh exited 1 silently and test/state-root-resolver-failure.test.ts failed there. Check readability first. - The merge fixture now lives under a path with a space and an apostrophe, executes the printed command, and asserts same-directory variables agree. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(config): pin the %q-quoted recovery command and run it from a spaced install path Follow-up to #3186 (adopted from davidfragnoli-lang). Intentional pin change: the fix line's GSTACK_STATE_ROOT='<legacy>' pin becomes the exact bash printf %q form of the legacy root (the PR loosened it to a prefix check; this restores an exact pin) and the original test name is kept. Reviewer test: copy bin/ to a path containing a space and an apostrophe; the printed fix: command runs cleanly and flips the merged value. Fails on 47d639a (unquoted $_SELF), passes with #3186. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * test(gstack-gbrain-sync): fail when a star gitignore already ignores the pin ensureGbrainSourceGitignored appends .gbrain-source even when git check-ignore already excludes that path. The extra line dirties a tracked ignore-everything gitignore. * fix(gstack-gbrain-sync): skip the pin line when git already ignores it ensureGbrainSourceGitignored asked only for a literal .gbrain-source line. An ignore-everything star already excludes the pin, and the extra line left the tracked gitignore dirty. * fix(gbrain-sync): only a tracked .gitignore can stand in for the pin line Follow-up to #3178 (adopted from KuroChen). The skip now requires `git -c core.excludesFile= check-ignore -v` to name a tracked .gitignore (not global excludes, not .git/info/exclude, not a negation), so a pin ignored only on this machine still gets the shared line teammates need (#1384). Tests: the two git init spawns get timeouts (they failed the spawnSync tripwire), fixtures isolate HOME/XDG_CONFIG_HOME, and the PR's star-gitignore fixture stages its .gitignore (intentional fixture change: the contract is a tracked file). Reviewer tests: global excludes only, info/exclude only, an untracked star .gitignore, and a re-include each still append; all three fail on the PR head. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(skill-end): log the completion event before the final drain (#3198) gstack-skill-end drained and pushed before it appended its own completed timeline event, and gstack-timeline-log backgrounded its enqueue, so a full-tier end boundary returned with its latest event unpushed. The completion log now runs before the drain and the logger waits for its enqueue (one config read and a spool write; it exits early when sync is off or the session is unattended). Every consent, secret-scan and queue-lock gate is unchanged; the stale "local-only, never sent anywhere" comment is replaced. Patch and regression test from Kkkkkuro (#3198): 2 pass / 5 fail on 47d639a, 8/8 with the fix. Reviewer test: with artifacts_sync_mode off the completion is written locally with no queue entry and no push. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(pregate): map Next.js route paths and tsconfig path aliases to their tests QUOTED excluded ( ) [ ] +, so a test naming app/(app)/page.tsx in a string never matched. resolveRef never read tsconfig compilerOptions.paths, so an import through @/ resolved to nothing. Both were PREGATE_NO_LANE false negatives in a Next.js App Router repo whose tests did name the files. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(pregate): TypeScript alias precedence, relative extends and a no-lane explanation Follow-up to #3176 (adopted from vocodestudios). Path aliases now follow TypeScript's choice: an exact pattern, else the wildcard with the longest prefix, targets tried in order. When the chosen pattern resolves nothing, every plausible reading (other matching patterns, baseUrl, the repo root) gains the edge, so uncertainty selects more tests, never fewer. Relative extends chains are followed up to MAX_TSCONFIG_EXTENDS (4) hops, with baseUrl and paths resolved against the config that declares them. Trailing commas are dropped by the JSONC tokenizer (never inside a string) instead of a whole-text regex. A touched file with no lane now gets explain lines naming the import specifiers in test files that resolved to no repo file, any extends hop that was not followed (with the limit), and the hint to declare the file under dependencies or report the resolver gap. The lines ride testsFor's provenance, which lanes already pushes to --explain. Reviewer tests: overlapping aliases in both key orders, exact vs wildcard, target fallback, the union case, a two-hop extends chain, a string containing ',]', and the depth-limit explanation. Five fail on the PR head; all 12 pass. The manifest-parser half of #3176's follow-up (lane-selection.ts) ships in PR 2. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(browse): reap PTY children on agent shutdown * fix(browse): reap a terminal-agent PTY's whole process group at shutdown (#3147) Follow-up to #3148 (adopted from Y4NN777). The PTY child leads its own session and process group; its identity (pgid, sid, leader start time) is recorded at spawn and stays checkable after the leader exits. Disposal schedules a group reap after PTY_SHUTDOWN_GRACE_MS that, unlike the direct-child SIGKILL fallback, is not cancelled when the leader exits, and shutdown reaps every pending group before exiting, so descendants that ignore SIGHUP no longer outlive the agent. Only proven members are signalled: same pgid and sid, started no earlier than the leader, and nothing at all when the leader's PID is held by a process with another start time. Linux only (/proc); other platforms keep the direct-child behavior. During the shutdown grace the server answers 503 and no new PTY is spawned. Test changes to the PR's own test (intentional): the agent is spawned with process.execPath and the PTY child traps INT TERM HUP, so the case proves the SIGKILL fallback instead of passing on the kernel hangup. Reviewer tests: a HUP-immune grandchild is dead within the grace plus 1 s; an early-exiting leader's surviving descendant is reaped; a session that completed before shutdown still has its group reaped; unit cases for a foreign group and a reused leader PID. All four integration cases fail on 47d639a; three fail on the PR head. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * build(deps): bump the github-actions group with 5 updates Bumps the github-actions group with 5 updates: | Package | From | To | | --- | --- | --- | | [actions/upload-artifact](https://github.com/actions/upload-artifact) | `7.0.1` | `7.0.2` | | [actions/download-artifact](https://github.com/actions/download-artifact) | `8.0.1` | `8.0.2` | | [actions/setup-node](https://github.com/actions/setup-node) | `7.0.0` | `7.1.0` | | [ossf/scorecard-action](https://github.com/ossf/scorecard-action) | `2.4.4` | `2.5.0` | | [github/codeql-action/upload-sarif](https://github.com/github/codeql-action) | `4.38.2` | `4.38.3` | Updates `actions/upload-artifact` from 7.0.1 to 7.0.2 - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](https://github.com/actions/upload-artifact/compare/043fb46d1a93c77aae656e7c1c64a875d1fc6a0a...cf430e030ddbb5b0abf93d22962f4752f3646cd9) Updates `actions/download-artifact` from 8.0.1 to 8.0.2 - [Release notes](https://github.com/actions/download-artifact/releases) - [Commits](https://github.com/actions/download-artifact/compare/3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c...9000827ccba6bdab643e8b6fd33ac0654aef8333) Updates `actions/setup-node` from 7.0.0 to 7.1.0 - [Release notes](https://github.com/actions/setup-node/releases) - [Commits](https://github.com/actions/setup-node/compare/820762786026740c76f36085b0efc47a31fe5020...949feb2413d6458794dcd2491c4babbbce0c15c1) Updates `ossf/scorecard-action` from 2.4.4 to 2.5.0 - [Release notes](https://github.com/ossf/scorecard-action/releases) - [Changelog](https://github.com/ossf/scorecard-action/blob/main/RELEASE.md) - [Commits](https://github.com/ossf/scorecard-action/compare/2d1146689b8cda280b9bc96326124645441f03bc...fa7117db83c52d787ae5a89f350999701505d78e) Updates `github/codeql-action/upload-sarif` from 4.38.2 to 4.38.3 - [Release notes](https://github.com/github/codeql-action/releases) - [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md) - [Commits](https://github.com/github/codeql-action/compare/2892aa5e19bbd11bc0cff5427e3b750a04d9e3c2...24c54180a607b1449ed407dd24f251e4e9147c8d) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: 7.0.2 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: github-actions - dependency-name: actions/download-artifact dependency-version: 8.0.2 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: github-actions - dependency-name: actions/setup-node dependency-version: 7.1.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: github-actions - dependency-name: ossf/scorecard-action dependency-version: 2.5.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: github-actions - dependency-name: github/codeql-action/upload-sarif dependency-version: 4.38.3 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: github-actions ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * test(model-policy): track the upload-artifact v7.0.2 pin from #3175 Intentional pin change: test/model-policy-workflow.test.ts asserted actions/upload-artifact@043fb46d…; dependabot #3175 moves the workflow to cf430e03… (v7.0.2, verified against the upstream tag). The pin tracks the workflow. #3175's free-tests.yml hunk is left out of this PR (free-tests.yml is a #3190 file; it is re-bumped in PR 5). Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * test(model-policy): its upload-artifact pin matches the eval workflows' pin Reviewer test for dependabot #3175: the model-policy workflow's single upload-artifact pin equals the pin evals.yml, evals-periodic.yml and windows-free-tests.yml use, so a group bump that misses one workflow (or the hard-coded pin above) is caught here. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * build(deps): hold Playwright minor/major bumps behind the windowsHide patch (#2923) Dependabot #2923 bumped playwright to ^1.64.0 and dropped the patchedDependencies entry keyed to playwright-core@1.62.1, which keeps windowsHide on Windows (#2160, #1989). The bun ecosystem now ignores only semver-minor and semver-major updates for playwright and playwright-core; patch updates still flow. The 1.64 migration (re-key the patch, the Dia/cookie qualification pins, the arm64 artifact name) is filed with owner Garry, revisit 2026-11-15. Test fails on 47d639a (no ignore rule). Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * docs(readme): drop the stale skill lists users pasted into CLAUDE.md (#3169) README's install prompt and troubleshooting block each carried a skill list for CLAUDE.md; both were stale (18 shipped skills missing) and they disagreed. Claude Code lists installed skills itself, so both now keep only the /browse rule, and the troubleshooting entry says to delete an old pasted list. New free test: any comma-separated skill list in README.md or CLAUDE.md must name exactly the shipped skills (with a negative control for the detector). Fails on 47d639a; passes now. Reported by the #3169 issue author. The matching doctor warning for pasted lists ships in PR 5. Intentional pin change: test/test-value-bar.test.ts no longer expects the README skill list to name /test-audit twice; it now expects that list to be gone (0 occurrences), the registration this commit removes on purpose. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * chore(osv): image-size has a fix; html-to-docx's ^1.0.0 pin blocks it (#2753) The image-size ledger said no fixed release exists. OSV lists 2.0.3 as fixed for GHSA-5p2g-fcmc-qvqq and GHSA-w3rx-r6r6-pgpr (checked against api.osv.dev), but html-to-docx@1.8.0 pins image-size ^1.0.0 and there is no fixed 1.x, so the fix is a cross-major override. Both entries now say so and name the upgrade trigger; the 2026-11-30 expiry is kept. New test checks the wording and that bun.lock still shows the stated pin (it fails on 47d639a). Correction first raised on #2753 by sonukapoor. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * feat(ios-qa): forward GSTACK_IOS_LAUNCH_ENV to devicectl launches (#1796) Reimplements only the launch-environment half of #1796 (credit Bmathews721; the session-cache half is superseded by #3132's design and had state-root and symlink-write problems). devicectl.ts parses GSTACK_IOS_LAUNCH_ENV as a JSON object of string to string; launchEnvArgs() returns the --environment-variables argv (empty when unset or {}) and launchApp passes it before the bundle id. Invalid JSON, a non-object, a non-string value, a bad name or a key in the debug bridge's reserved GSTACK_ namespace refuses before any launch with the new result code IOS_LAUNCH_ENV_INVALID (the detail names keys and types, never values). launchEnvArgs is exported for the forced-relaunch path in tunnel-bootstrap.ts. Adds the result-code row (bin/gstack-doctor-components.sh regenerated by gen:skill-docs), a troubleshooting entry under its exact text, the pregate-no-lane entry's explain note, and the how-to section with an example. New test fails on 47d639a (module load: no parseLaunchEnv). Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(deps): declare sharp and clear two transitive advisories sharp is imported in four files, including browse/src/screenshot-size-guard.ts, and test/dependency-security.test.ts asserts a >=0.35.4 floor on it and loads it. It was declared in no dependency field, reaching the tree only through @huggingface/transformers with the overrides pin forcing the version. Declare it at ^0.35.4, matching the floor that test already asserts. Upgrade @huggingface/transformers to ^4.3.0, which clears sprintf-js@1.1.3 and aligns the sharp override with what the parent declares: 4.2.0 declared sharp ^0.34.5 while the override pins 0.35.5, which is outside that range, and 4.3.0 declares ^0.35.4. Upgrade @anthropic-ai/claude-agent-sdk to 0.2.141, which clears @anthropic-ai/sdk@0.81.0. The existing overrides entry for sharp is left in place. * test(deps): sharp is declared and its override satisfies every asking range Reviewer test for #3145 (adopted from sonukapoor): sharp must be a declared dependency, and the pinned overrides.sharp must satisfy both that declaration and every lockfile package that depends on sharp (@huggingface/transformers included). Fails on 47d639a (sharp not declared; transformers 4.2.0 asked for ^0.34.5 against a 0.35.5 pin). Classifier smoke on the changed tree (transformers 4.3.0, onnxruntime-node 1.30.0, sharp 0.35.5, claude-agent-sdk 0.2.141): the real sidecar entry bundled for Node with a private state root, and the classifier in-process under Bun, each downloaded the TestSavantAI model fresh, reported testsavant: ok, and returned scores identical to 47d639a's tree on five inputs, including a >512-token input that exercises the truncation override. dependency-security, deps-smoke, overlay-sdk-cancel-eof, security-classifier and screenshot-size-guard pass; typecheck:test reports no new diagnostics. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(gbrain-sync): the no-bash skip names GSTACK_GIT_BASH and how to set it (#3197) The brain-sync stage's Windows skip line told users to set GSTACK_BASH. After the fix wave the canonical override is GSTACK_GIT_BASH, with GSTACK_BASH as a deprecated alias (plan correction 9). The summary is now the exported NO_BASH_SUMMARY: it names GSTACK_GIT_BASH first and GSTACK_BASH as the old name, and gives the two recipes that reach Claude Code (a PowerShell user environment variable plus a Claude Code restart, or the "env" block of ~/.claude/settings.json). Minimal on purpose: once PR 2 lands, this switches to lib/script-invocation.ts noBashMessage(). Until then lib/gbrain-exec.ts still reads only GSTACK_BASH, so this line is accurate only with PR 2 merged first. New test test/gbrain-sync-no-bash-message.test.ts fails on the previous commit (NO_BASH_SUMMARY not exported) and passes now. Handoff from Lane C (PR 2). Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix(ios-qa): the forced relaunch carries GSTACK_IOS_LAUNCH_ENV too (#1796) bootstrapTunnel's relaunchApp (an app whose boot token an earlier daemon consumed is relaunched once with --terminate-existing) built its own devicectl argv and dropped GSTACK_IOS_LAUNCH_ENV, so an env-gated debug bridge vanished after the one relaunch the howto says carries it. It now uses launchEnvArgs(); an invalid value refuses the relaunch with launch_failed and the IOS_LAUNCH_ENV_INVALID detail before anything is terminated. Two new tests in ios-qa/daemon/test/devicectl-launch-env.test.ts drive bootstrapTunnel through a consumed-token device: both fail on the previous commit (relaunch argv lacks --environment-variables; the invalid value still terminates and relaunches) and pass now. ios-qa daemon: 167 pass. tunnel-bootstrap.ts was assigned to Lane D by the coordinator for this fix. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * ci(version-gate): check the version queue only on PRs into main Stacked layer PRs carry no VERSION stamp by design (the release layer stamps once), so the queue check failed on any layer touching package.json. The queue and its collision rule only describe main; a PR into main is still checked exactly as before. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * test(browse): scope the SIGTERM PTY-reap case to POSIX signals (#3147) windows-free-tests run 38813751242 (shard 6) failed "SIGTERM reaps every active PTY child before terminal-agent exits" with "timed out waiting for pty…

time-attack mentioned this pull request Jul 14, 2026

fix: reconstruct the setup/install safety wave time-attack/gstack#7

Closed

garrytan mentioned this pull request Sep 4, 2026

v1.80.0.0 fix: setup survives a failed Chromium install, hooks share one state root, gstack never clobbers a skill it did not create #2802

Merged

4 tasks done

garrytan mentioned this pull request Sep 6, 2026

v1.81.0.0 feat: Aside is the browser gstack drives first; every browsing skill, the PDF/diagram renderer, and web research; the bundled browser stays the automatic fallback #2810

Merged

9 of 10 tasks

capy-ai Bot closed this Oct 3, 2026

szsunyuan mentioned this pull request Oct 12, 2026

fix(setup): remove 1.31-era unprefixed Cursor skill folders (#3133) #3152

Closed

8 of 9 tasks

Navigation Menu

Repository navigation

fix(relink): don't clobber foreign skills that share a gstack name - #2119

fix(relink): don't clobber foreign skills that share a gstack name#2119
smblight wants to merge 1 commit into
garrytan:mainfrom
smblight:fix/relink-preserve-foreign-skills

smblight commented Jun 26, 2026

Uh oh!

trunk-io Bot commented Jun 26, 2026

Uh oh!

time-attack commented Jul 15, 2026

Uh oh!

time-attack commented Jul 15, 2026 •

edited

Loading

Uh oh!

capy-ai Bot commented Oct 3, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

smblight commented Jun 26, 2026

Problem

Root cause

Fix

Tests

Uh oh!

trunk-io Bot commented Jun 26, 2026

Uh oh!

time-attack commented Jul 15, 2026

Uh oh!

time-attack commented Jul 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

capy-ai Bot commented Oct 3, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

time-attack commented Jul 15, 2026 •

edited

Loading