R6: pure-Zig native paths + dev↔main reconcile → main

[Eugene3dotdev]

Lands ponytail's R6 on main: dev↔main reconcile (absorbs main's CVE fix + upstream merge) + pure-Zig native install paths.

What changed

• Reconcile: main's 8 commits absorbed — CVE-2026-25536 (MCP SDK), Windows-portability (fix: make Python command portable in robustness-audit.js (fixes Windows) DietrichGebert/ponytail#209), statusline shell-safety (fix: don't embed shell-unsafe install paths in statusline setup nudge DietrichGebert/ponytail#224), DietrichGebert upstream merge. The 4 Zig conflicts kept dev's getDefaultMode owned-return fix.
• install.sh / install.ps1 / release-binaries.yml ship prebuilt Zig binaries.
• Native hooks (Claude Code / Codex / Copilot) → bin/ponytail-launch ponytail-{activate,hook}. main.zig command surface ports the full retired JS syntax (@Ponytail, /ponytail-review, off, namespaced, stop ponytail).
• Deleted ponytail-{activate,mode-tracker,runtime}.js + ponytail-mcp/ (the CVE-vulnerable SDK dep gone entirely; Zig ponytail-mcp binary replaces it).

Honest scope

The pi-extension chain stays JS (pi mandates ESM): config→fs-safe→instructions→instructions-bin. Native paths are pure Zig; pi runtime keeps its JS shim layer.

Review

P1 command-parity + P2 Windows commandWindows fixed + verified (runtime: every command form maps correctly; commandWindows → ponytail-launch.ps1). CodeRabbit Majors on release-binaries.yml applied (perms scoped, tag validated, binary-set asserted, no empty SHA256SUMS). build+test+fmt exit 0.

Deferred

Windows binaries = R6-Windows. benchmarks/robustness-audit.js execSync (CodeRabbit Minor, merged-from-main benchmark tool) — out of R6 scope.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• New Features

  • Added automated release binary builds with SHA-256 checksum publishing.
  • Introduced cross-platform launchers and installer shims to resolve and run the native runtime automatically.
  • Updated hook wiring to use the new launchers and increased hook timeouts to 30s.

• Bug Fixes

  • Improved prompt/mode parsing and default-mode handling, including safer behavior under memory pressure.

• Chores / Tests

  • Updated and strengthened Windows/macOS/Linux hook and installer consistency tests.

• Breaking Changes

  • Removed prior Node-based hook runtime and the MCP server components.

Walkthrough

Adds a release workflow for version-tagged binaries, new Bash and PowerShell launchers, installer shims, hook manifest rewiring, and Zig runtime changes for fallible default-mode lookup and expanded prompt parsing.

Changes

Pure-Zig runtime cutover

Layer / File(s)	Summary
Release binaries workflow .github/workflows/release-binaries.yml	Validates v<semver> tags, builds per-platform archives and checksum sidecars, and publishes an aggregated SHA256SUMS manifest.
Launchers and hook rewiring bin/ponytail-launch, bin/ponytail-launch.ps1, hooks/claude-codex-hooks.json, hooks/copilot-hooks.json	Replaces Node-based hook commands with launcher entry points, and adds the Bash/PowerShell launchers that resolve binaries from hooks, local builds, or cached downloads.
Installers and hook tests install.sh, install.ps1, tests/hooks-windows.test.js, tests/hooks.test.js	Adds the shell and PowerShell installer shims, symlink-safe deployment and settings wiring, and updated tests for launcher-based hook execution and install consistency.
Zig prompt parsing and default-mode handling zig/src/common.zig, zig/src/activate.zig, zig/src/instructions.zig, zig/src/mcp.zig, zig/src/main.zig	Makes getDefaultMode fallible, updates callers, and replaces slash-only prompt parsing with multi-sigil Action handling plus new parsing tests.

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~120 minutes

Possibly related PRs

• EugOT/ponytail#1: Shares the same Zig hook/runtime hardening path around safe flag writes and statusline behavior.
• EugOT/ponytail#2: Overlaps on the getDefaultMode fallible API change and caller updates.
• EugOT/ponytail#4: Directly overlaps on launcher rewiring, release packaging, and removal of the prior JS hook/runtime entry points.

Poem

🐇 I hop through tags and archives neat,
With Zig-built bins and checksums sweet.
/, @, and $ all know my call,
The ponytail answers one and all.
From cache to hook, the paths align—
A rabbit’s launch is now divine.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 61.54% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	It is concise and accurately reflects the main changes: pure-Zig native paths plus reconciling dev with main.
Description check	✅ Passed	The description is detailed and clearly matches the PR's actual changes, including native paths, hook updates, and removals.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch dev

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 13

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/release-binaries.yml:
- Around line 62-64: The cross-compile step in the release workflow expands
matrix.target.triple directly inside the run shell, which static analysis flags
as template-injection; move that value into the step’s env for consistency with
the RAW_TAG hardening and update the nix develop/zig build command to reference
the environment variable instead. Use the existing “Cross-compile ponytail for
…” job step and the matrix.target.triple symbol to locate the change.
- Around line 12-13: Add the required ponytail marker to the deferred-Windows
note in the release-binaries workflow comment so the intentional macOS +
Linux-only simplification is discoverable by convention. Update the existing
explanatory comment near the Windows deferral to start with ponytail: and
include the known ceiling plus upgrade path, keeping the same meaning but making
the marker explicit.
- Around line 44-53: Resolve and validate the release tag before any repository
checkout, then use that validated tag as the ref for both actions/checkout
steps. In the release workflow, update the checkout logic around the Resolve and
validate release tag step so the build always uses the same tag being published,
preventing a manual run from compiling the triggering branch while labeling
artifacts with inputs.tag. Ensure the tag value flows only from the validated
tag output into checkout, release asset creation, and checksum generation.
- Line 44: The workflow still uses floating action tags and leaves checkout
credentials persisted, so update both checkout steps in the release-binaries
workflow to disable credential persistence via the checkout action settings, and
replace the current tagged uses of actions/checkout and
softprops/action-gh-release with pinned full commit SHAs while keeping the
human-readable version in a comment. Make sure the changes are applied
consistently wherever those actions are referenced so the build and release jobs
stay reproducible and do not reuse the token from .git/config.
- Around line 15-18: The release workflow trigger currently allows overlapping
runs for the same version, which can race release creation and asset uploads.
Add a concurrency guard to the workflow using a tag/version-derived group so
runs for the same release serialize or cancel, and place it alongside the
existing on/push/tags and workflow_dispatch triggers in the release workflow
definition.

In `@bin/ponytail-launch.ps1`:
- Around line 19-23: Add a ponytail: comment in the Windows no-download/no-op
branch of ponytail-launch.ps1, near the logic that exits 0 when no binary
resolves. Use the existing local/cache resolution flow and explicitly note the
known ceiling (no Windows archive yet, silent no-op) plus the upgrade path once
the Windows binary ships, so the intentional simplification is documented.

In `@install.ps1`:
- Around line 8-13: The Windows no-op installer in the install script is an
intentional simplification and should be marked with a ponytail: comment. Update
the comment near the Windows install path handling to explicitly note the
current ceiling (accepts flags and exits 0 without installing) and the upgrade
path (plugin marketplace/bin/ponytail-launch until R6-Windows ships), using the
existing install flow symbols so the intent is clear.

In `@install.sh`:
- Around line 177-181: Add the required ponytail: marker to the settings-writer
shortcut comments in install.sh, including the fresh-file-only settings.json
wiring and the already_installed() grep-based idempotency probe. Update the
existing explanatory comments near the settings writer logic to explicitly name
the intentional ceiling and the upgrade path, keeping the reference points in
the same shell block that handles settings.json wiring and idempotency checking.
- Around line 158-175: The symlink checks in safe_install_file only validate the
destination and immediate parent before mv -f, so the install can still be raced
by swapping an ancestor path after the pre-check. Tighten the implementation to
make the final write atomic and revalidated at the last possible moment, using
safe path handling around safe_install_file’s mktemp/cp/chmod/mv sequence so the
destination cannot be redirected outside the intended hooks directory.
- Around line 257-279: In the install flow in install.sh, the branch that
handles a non-empty settings.json not already handled by already_installed only
prints manual wiring instructions but then falls through to the success
messages. Update that path to stop the install as a failure (or return early
before the final “Done!”/“What's installed” output) so the script does not
report success when wire_settings_fresh was not applied. Use the existing
already_installed and wire_settings_fresh decision block to keep the success
message only for actually wired installs.
- Around line 182-207: The fresh settings writer in wire_settings_fresh() is
emitting unquoted hook command paths into settings.json, which breaks installs
when HOOKS_DIR or related base paths contain spaces. Update the command values
for ponytail-activate, ponytail-hook, and ponytail-statusline so they are quoted
consistently with the plugin manifests before being written, ensuring the
generated JSON preserves each full path as a single shell-parsed command string.

In `@tests/hooks-windows.test.js`:
- Around line 56-71: The windows hook test currently only verifies
bin/ponytail-launch exists, so it can miss a missing PowerShell launcher
artifact. Update the existing test in commandWindows/allCommands to also assert
that bin/ponytail-launch.ps1 exists on disk, alongside the current resolver
check, so packaging regressions for Windows hooks are caught.

In `@tests/hooks.test.js`:
- Around line 2-32: The current tests only cover the helper contract in
ponytail-config via isShellSafe and no longer exercise the launcher/install
flow. Add back at least one smoke test that covers the new executable path for
bin/ponytail-launch and install.sh, including the manifest-to-binary wiring, so
regressions in the shell layer are caught. Keep the existing isShellSafe checks
in tests/hooks.test.js, but supplement them with a real end-to-end invocation
tied to the launcher/install entrypoints.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: e628f7d8-b6b2-4487-8d34-6a40ad46ca55

📥 Commits

Reviewing files that changed from the base of the PR and between eb0b47b and 9d59544.

📒 Files selected for processing (22)

• .github/workflows/release-binaries.yml
• bin/ponytail-launch
• bin/ponytail-launch.ps1
• hooks/claude-codex-hooks.json
• hooks/copilot-hooks.json
• hooks/ponytail-activate.js
• hooks/ponytail-mode-tracker.js
• hooks/ponytail-runtime.js
• install.ps1
• install.sh
• ponytail-mcp/README.md
• ponytail-mcp/index.js
• ponytail-mcp/instructions.js
• ponytail-mcp/package.json
• ponytail-mcp/test/instructions.test.js
• tests/hooks-windows.test.js
• tests/hooks.test.js
• zig/src/activate.zig
• zig/src/common.zig
• zig/src/instructions.zig
• zig/src/main.zig
• zig/src/mcp.zig

🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

• EugOT/dotfiles (manual) → reviewed against branch dev instead of the default branch

💤 Files with no reviewable changes (8)

• ponytail-mcp/test/instructions.test.js
• hooks/ponytail-activate.js
• ponytail-mcp/package.json
• hooks/ponytail-mode-tracker.js
• ponytail-mcp/README.md
• ponytail-mcp/index.js
• ponytail-mcp/instructions.js
• hooks/ponytail-runtime.js

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@tests/hooks.test.js`:
- Around line 89-95: The wiring assertion in the hook install test is too broad
because `installSh.includes(name)` can be satisfied by the hook list declaration
instead of the settings-writing logic. Update the test around
`wire_settings_fresh` to extract or target the settings-writer body in
`installSh`, and assert that it references `$HOOKS_DIR/<name>` for each deployed
hook. Use the existing `deployed` loop and the `wire_settings_fresh` symbol to
keep the check scoped to the code that writes `settings.json`.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 9f4a03c7-e7ac-4c29-8187-9de645c39485

📥 Commits

Reviewing files that changed from the base of the PR and between 9d59544 and fad48fa.

📒 Files selected for processing (6)

• .github/workflows/release-binaries.yml
• bin/ponytail-launch.ps1
• install.ps1
• install.sh
• tests/hooks-windows.test.js
• tests/hooks.test.js

🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

• EugOT/dotfiles (manual) → reviewed against branch dev instead of the default branch

[coderabbitai]

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Scope the wiring assertion to wire_settings_fresh.

installSh.includes(name) is tautological because each name came from HOOK_BINS=(...) in the same file. Extract the settings-writer body and assert it references $HOOKS_DIR/<name>.

Proposed fix

 	// install.sh's wire_settings_fresh must reference each deployed hook so the
 	// settings.json it writes actually points at the binaries it lays down.
+	const wiringMatch = installSh.match(/wire_settings_fresh\(\) \{([\s\S]*?)\n\}/);
+	assert.ok(wiringMatch, "install.sh must define wire_settings_fresh()");
+	const wiring = wiringMatch[1];
 	for (const name of deployed) {
 		assert.ok(
-			installSh.includes(name),
+			wiring.includes(`$HOOKS_DIR/${name}`),
 			`install.sh deploys '${name}' but never references it in settings wiring`,
 		);
 	}

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	// install.sh's wire_settings_fresh must reference each deployed hook so the
	// settings.json it writes actually points at the binaries it lays down.
	for (const name of deployed) {
	assert.ok(
	installSh.includes(name),
	`install.sh deploys '${name}' but never references it in settings wiring`,
	);
	// install.sh's wire_settings_fresh must reference each deployed hook so the
	// settings.json it writes actually points at the binaries it lays down.
	const wiringMatch = installSh.match(/wire_settings_fresh\(\) \{([\s\S]*?)\n\}/);
	assert.ok(wiringMatch, "install.sh must define wire_settings_fresh()");
	const wiring = wiringMatch[1];
	for (const name of deployed) {
	assert.ok(
	wiring.includes(`$HOOKS_DIR/${name}`),
	`install.sh deploys '${name}' but never references it in settings wiring`,
	);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/hooks.test.js` around lines 89 - 95, The wiring assertion in the hook
install test is too broad because `installSh.includes(name)` can be satisfied by
the hook list declaration instead of the settings-writing logic. Update the test
around `wire_settings_fresh` to extract or target the settings-writer body in
`installSh`, and assert that it references `$HOOKS_DIR/<name>` for each deployed
hook. Use the existing `deployed` loop and the `wire_settings_fresh` symbol to
keep the check scoped to the code that writes `settings.json`.