[miguel-heygen]

What

hyperframes init into a folder directly under a Windows drive root (init D:\my-video) no longer crashes. It used to end with exit code -1073740791 (0xC0000409) and write no project files. The same command with the target one folder deeper, or on a subst drive, worked.

Why

Users on Windows reported it, with the workaround "init on C: then move". Init makes the project folder first and then copies the template into it. Node's fs.cpSync kills the process when its destination is a folder that already exists directly under a drive root, with or without a filter. That holds on C:, D: and an attached virtual disk alike, and with NTFS, ReFS, exFAT and FAT32. A destination that does not exist yet, or one a level deeper, copies fine.

Related work

None open. copyDirSync passed a filter to keep Node off its native copy, which wrote nothing under a non-ASCII path on Windows (init.nonAsciiPath.test.ts). A filtered cpSync still runs into the same crash.

How

copyDirSync, the CLI's one directory copy (init's template and the skills mirror), copies with readdirSync, mkdirSync and copyFileSync, merging into what is there and keeping symlinks as symlinks. It no longer calls fs.cpSync. Its options parameter had no caller and is gone.

compare.ts and the media-use recipe store still call cpSync, into temp folders and the user's ~/.hyperframes, never a drive root. They are left alone.

Test plan

• Unit tests added/updated: copyDir.test.ts copies a tree with non-ASCII names into a folder that already holds files. On Windows only, it also copies into an existing folder directly under the temp folder's drive root. That case fails without the fix: on windows-latest, with the old copyDirSync, the Vitest worker dies ("Worker exited unexpectedly").
• Manual testing performed: on windows-latest with Node 22, the published 0.9.13 init C:\hfroot-… and init D:\hfroot-… into existing root folders exit 0xC0000409 with no files. This branch's CLI exits 0 with the six project files in each. copyDir, init, init.nonAsciiPath and skillsMirror tests pass on windows-latest. oxfmt and oxlint pass on the changed files.
• Documentation updated (if applicable): no user-facing flag or behaviour changes beyond the fix.
• Comments follow CONTRIBUTING.md "Comments": copyDirSync's comment says why it does not use fs.cpSync and which destination crashes it.

Not exercised: Node 24 directly. The same crash was reported from an app that runs the CLI on Node 24.

Size

About 60 lines: one helper and its test. A lone fix for a crash no open PR touches, so nothing can carry it.

[github-actions]

Edit accuracy: accurate 267 (base branch 267), smooth 128 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (8)

• seqplainkeys-none-center-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): fail / pass / pass, passes
• seqplainkeys-none-center-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): fail / pass / pass, passes
• seqplainkeys-none-center-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-pct-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-pct-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
• seqplainkeys-none-px-r30-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
• seqplainkeys-none-px-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run

[heygengenesis]

Approving at 7e22db77. I found no blocker.

What I checked

• Fails-without-the-fix line: the Test plan bullet carries it. It names the test (copyDir.test.ts, "copies into an existing folder directly under a drive root") and the failure on windows-latest with the old copyDirSync ("Worker exited unexpectedly"). I can't run Windows from here, so I'm relying on the body's windows-latest evidence for that half.
• CI at this head is all green. The Windows engine-cli job ran both new tests and both passed ✓, including copies into an existing folder directly under a drive root.
• Linux local run passes: copyDir, skillsMirror and all init* tests (114 passed, 2 skipped as Windows-only).
• Callers: init makes destDir and then merges the template into it. copyFileSync overwrites the same way cpSync's default force did, and existing user files are kept; the new test covers that. skillsMirror.linkOrCopy runs rmSync on the target first, so the copy always lands in an empty folder.
• Symlinks: there are none under the templates or the skills, so the change in symlink handling doesn't affect today's inputs.

Non-blocking

• If the destination already has an entry with the same name, symlinkSync throws EEXIST, where cpSync used to replace it. No caller hits this today.
• A relative symlink is now copied exactly as written. cpSync (with verbatimSymlinks: false) rewrote it to an absolute path, so a relative link that points outside the copied tree would now break.
• Both are worth a line in the doc comment if a symlinked template ever shows up.