Fix assertion failure on Windows when loading varlock

[Copilot]

Fixes a critical bug on Windows where all varlock commands were failing with an assertion error: Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 76.

Root Cause

The issue was caused by calling gracefulExit() twice in error handling paths in cli-executable.ts:

1. When a known error occurred (CliExitError or InvalidEnvError), the error handling branch would call gracefulExit(1)
2. Then unconditionally, the final statement after the catch block would also call gracefulExit(1)

This double invocation caused libuv on Windows to attempt closing the same handle twice, resulting in the assertion failure.

Changes Made

Removed the two gracefulExit(1) calls from within the error handling branches. Now all known error paths fall through to a single gracefulExit(1) call at the end of the catch block. gracefulExit() is only called once per execution path:

• Success path: Line 91 calls gracefulExit()
• Known error paths: Lines 98 or 101 log the error, then fall through to line 108 which calls gracefulExit(1) once
• Unknown error path: Line 105 re-throws without calling gracefulExit

This approach provides cleaner code structure where all known errors converge to a single exit point.

Testing

• ✅ Built the package successfully
• ✅ Tested the CLI commands (load, --help) - no assertion failures
• ✅ All 135 existing tests pass
• ✅ Code review: No issues found
• ✅ Security scan: No vulnerabilities detected

The fix is minimal and surgical, addressing exactly the root cause without any side effects.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[BUG]: Assertion failure on Windows</issue_title>
<issue_description>### varlock version

v0.1.3

Steps to reproduce

Run varlock load on Windows with node v24.12.0

What is expected?

Environment variables are printed and the command exits successfully.

What is actually happening?

All varlock commands fail at the end with the same assertion failure:

> varlock load

✅ APP_ENV*
   └ "develop"
...
Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 76
 ELIFECYCLE  Command failed with exit code 3221226505.

System Info

System:
    OS: Windows 11 10.0.26100
    CPU: (32) x64 13th Gen Intel(R) Core(TM) i9-13980HX
    Memory: 26.39 GB / 63.68 GB
  npmPackages:
    @playwright/test: ^1.57.0 => 1.57.0
    @types/node: ~22.9.0 => 22.9.4
    eslint: 8.57.0 => 8.57.0
    prettier: ~2.8.8 => 2.8.8
    varlock: ^0.1.2 => 0.1.3

Any additional comments?

Fresh installs of everything. The same commands work flawlessly in Linux and Mac.</issue_description>

Comments on the Issue (you are @copilot in this section)

@philmillman Thanks for the report @MLNW, we'll take a look tomorrow

• Fixes [BUG]: Assertion failure on Windows #229

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 26a9bc6

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[theoephraim]

@copilot try again

[theoephraim]

@copilot - try again

[theoephraim]

@copilot try again

[Copilot]

@copilot try again

Fixed in commit 26a9bc6. The issue was a duplicate gracefulExit(1) call causing Windows libuv to close handles twice. Removed the redundant call - all tests pass.

[theoephraim]

@copilot - im not sure about removing that call to gracefulExit. I guess we could remove the other 2 calls to gracefulExit instead?

[Copilot]

@copilot - im not sure about removing that call to gracefulExit. I guess we could remove the other 2 calls to gracefulExit instead?

Good point! Fixed in commit 0564095 using your suggested approach - removed the two gracefulExit(1) calls from error branches instead. All errors now fall through to the single exit point at the end. All tests pass.