Windows: tracked skills symlink materialises as a plain file without Developer Mode #554

Activity

1. mogul commented on Oct 29, 2026

   

   mogul

   on Oct 29, 2026

   ContributorAuthor

   More actions

   Related finding: PR CI only runs for PRs whose base is main

   Connecting this to the same Windows/CI-coverage theme, since it came out of the Windows validation work.

   Three workflows in .github/workflows/ gate their pull_request trigger on branches: [main]:

   Workflow	PR trigger
   ci.yml	pull_request: branches: [main] — also push and merge_group
   frontend-skills-qa.yml	pull_request: branches: [main]
   zizmor.yml	pull_request: branches: [main]
   pr-lint.yml	pull_request: (unfiltered) — runs for any base

   So a PR based on anything other than main gets only pr-lint.

   Observed on #555

   That PR is stacked on fix/validator-windows-exec-bit (#547), because the Windows test fixes cannot be demonstrated on main while #547's exec-bit defect is unfixed. Its head ecba5a5 has exactly one check:

   Conventional Commit Title = success
   

   No Python Lint & Test, no Pattern Validation, no acq-kits Tests. The change is tests-only, so the risk is modest — but a stacked PR landing without the Python suite having run is a gap, and the PR body has to say "CI is authoritative" while CI is in fact not running.

   Why this matters more now

   Stacking is the natural way to land a dependent change here, and the Windows epic produces dependent changes by construction (validator fix → harness fix; CRLF fix → guard fix). A filter that silences CI for exactly those PRs makes the stacked pattern unsafe rather than merely awkward.

   Options

   1. Drop the branches: [main] filter on pull_request for ci.yml / frontend-skills-qa.yml / zizmor.yml. GitHub already scopes to PRs opened against this repository, so the filter buys little; the cost is CI minutes on PRs targeting a non-main base (few, and short-lived).
   2. Keep the filter and require unstacking before merge — rebase onto main once the base PR merges, then let CI run. Honest, but it means the reviewed diff and the CI-verified diff are different commits.
   3. Leave as-is and document it in CONTRIBUTING, so nobody reads a green PR as "tested".

   For contrast, the sibling repo is more permissive: GSA-TTS/agentic-coding-quickstart#667 is stacked on fix/648-msb-ports-crlf and still got 9/9 checks (pre-commit, the bash 3.2 suite, markdown, links, pr-lint). So this is repo-specific configuration, not an inherent property of stacking.

   Recommendation: option 1, with option 3 as the interim note.

   AI-assisted (OpenCode [deepseek-v4.1-flash]); human review required.
2. mogul commented on Oct 29, 2026

   

   mogul

   on Oct 29, 2026

   ContributorAuthor

   More actions

   One more data point for the options above: without the privilege, ln -s fails silently

   Measured on a default non-elevated Windows host (account in BUILTIN\Administrators, but a filtered Medium-integrity token, so SeCreateSymbolicLinkPrivilege is absent):

   $ whoami /priv | grep -i symlink
   (no output — privilege not held)
   
   $ ln -s target linkout
   ln -s: exit 0
   [ -d ] true (fell back to COPY)          <- exit code says success, result is a copy
   
   $ MSYS=winsymlinks:nativestrict ln -s target linkout
   ln: failed to create symbolic link: Operation not permitted
   

   Two things follow.

   1. ln -s success does not mean a link was created. MSYS/Git Bash falls back to copying unless MSYS=winsymlinks:nativestrict is set. Any script that asserts "link created" by exit status is fooled. Worth auditing any host-runnable script that links with ln -s and checks only $?.

   2. For reference, the kit path is not affected. integrations/isolation/acq-kits/agentic-coding-playbook/files/home/playbook-clone.sh links $HOME/.config/opencode/AGENTS.md, $HOME/.codex/AGENTS.md, $HOME/.claude/CLAUDE.md, $HOME/.copilot/copilot-instructions.md, and each skill into $HOME/.agents/skills/ — but it runs as a hybrid/v1 kit startup command inside the sandbox, so those ln -sfn calls execute against the guest's Linux filesystem. No Windows privilege is involved and no host mounts are used (checked: the only host-side reference to these paths in the quickstart backends is acq.backends/sbx.sh:1389, which runs sh -c via sbx exec in the guest to clear a dangling opencode.jsonc symlink).

   The host-side symlink exposure is therefore limited to the two cases in this issue: git materialising the tracked skills entry, and test fixtures calling os.symlink.

   Consequence for option 1 (require Developer Mode): if that is the chosen direction, the guidance should specify MSYS=winsymlinks:nativestrict for any host-run MSYS shell, so a missing privilege fails loudly instead of degrading into copies that look correct.

   AI-assisted (OpenCode [deepseek-v4.1-flash]); human review required.