install-lefthook postinstall fails on macOS when the repo path contains non-ASCII characters (NFC/NFD mismatch)

[mtemuralay]

Environment: macOS (Darwin 25.6), Apple Git 2.50.1 (core.precomposeunicode defaulting to true), Node 22, repository cloned under a path containing non-ASCII characters (e.g. …/Ai İçerikler/deepseek-harness).

Symptom: pnpm install fails at the root postinstall:

. postinstall$ node scripts/install-lefthook.mjs
. postinstall: [install-lefthook] new worktree-local merge.dsh-translation-pairing.name did not become the direct worktree value
. postinstall: Failed

With that first comparison patched, the next check fails the same way:

[install-lefthook] new worktree-local core.hooksPath did not become the effective direct worktree value

Cause: a Unicode-normalization (NFC/NFD) mismatch in scripts/install-lefthook.mjs path and value comparisons.

• On macOS the filesystem returns decomposed (NFD) names, so git rev-parse --show-toplevel / --absolute-git-dir yield NFD strings, and every path the script derives from them (worktreeConfigPath, hooksPath) is NFD.
• With core.precomposeunicode=true (the macOS default), git precomposes command-line arguments and prints --show-origin paths in NFC. So the origin path read back from git config --show-origin is NFC, and a path value stored via git config --worktree core.hooksPath <NFD path> reads back as NFC.
• normalizedPath() compares byte-for-byte (resolve(path) only), and the hooksPath verification compares installedEntry.value !== hooksPath directly, so both verifications fail on any repository path containing characters affected by normalization (İ, ç, ü, é, ä, CJK with combining marks, …). The installer then rolls back and postinstall exits 1.

Reproduction: on macOS, git clone the repository into a directory whose path contains e.g. İçerikler, then pnpm install.

Local workaround that made install pass:

1. .normalize('NFC') added to both sides of the comparison in normalizedPath(), and
2. git config core.precomposeunicode false in the clone (so values git stores and reports stay in the same NFD form the filesystem produces).

Suggested fix: apply NFC normalization consistently in the installer — in normalizedPath() and in every comparison of path-valued config (core.hooksPath, the ownership-marker checks) — rather than relying on git and Node agreeing on a normalization form. That removes the dependency on the core.precomposeunicode setting entirely.

Happy to provide more diagnostics if useful.

🤖 Diagnosed with Claude Code

[argszero]

Thanks for the detailed report — the diagnosis is exactly right, and I verified it against the installer at HEAD b150a551b8 (v0.1.1-rc.2). Two things to add: the precise gate each of your two errors trips, and the set of comparisons that would still need fixing after the normalizedPath() change.

Confirmed from source: no Unicode normalization anywhere.

// scripts/install-lefthook.mjs:569-572
function normalizedPath(path) {
  const normalized = resolve(path)
  return process.platform === 'win32' ? normalized.toLowerCase() : normalized
}

resolve() + win32-only toLowerCase(); no .normalize(). Every origin/path gate funnels through this helper:

• :223 isCurrent (dormant worktree-config guard),
• :518-520 isRegisteredOwnedHooksPath,
• :582 originIsFile — used at :650, :659, :752, :789.

Error 1 — merge.dsh-translation-pairing.name did not become the direct worktree value (thrown at :652): the value compared at :649 is a plain-ASCII driver name, so installed[0]?.value !== expected cannot be the trigger. The failing condition is !originIsFile(installed[0].origin, root, worktreeConfigPath) at :650: the origin read back from --show-origin is precomposed (NFC) by git while worktreeConfigPath is built from --absolute-git-dir output (NFD on your filesystem), and normalizedPath compares them byte-for-byte. Your one-line .normalize('NFC') addition fixes this site.

Error 2 — core.hooksPath did not become the effective direct worktree value (thrown at :791): here the trigger is the other condition — :788 installedEntry.value !== hooksPath. That is a direct string comparison that bypasses normalizedPath() entirely, so the normalizedPath() fix alone does not cover it (the sibling !originIsFile at :789 is covered, but the value check is not). This matches what you observed after patching the first comparison.

The layer worth adding: the direct comparisons of path-valued config. Once a worktree core.hooksPath exists (i.e. a second run, or a relocated hooks dir), these have the same NFC/NFD hazard and are not routed through normalizedPath():

• :788 installedEntry.value !== hooksPath (the one you hit),
• :732 / :743 / :783 worktreePath === hooksPath (relocation detection — worktreePath is the value read back through git, hooksPath is derived from --absolute-git-dir; on your setup these are NFC vs NFD, so a self-written path would be misjudged as a relocation and refuse/relocate),
• :523 / :744 / :770 ownership-marker content comparisons (inspectOwnedHooksDirectory(hooksPath)?.hooksPath === hooksPath etc.) — marker content round-trips through fs, so it stays in the script's form and matches hooksPath, but a marker written by a differently-normalized run would not.

Suggested shape: keep normalizedPath() for path-derived values and add a tiny samePath(a, b) helper (NFC-normalize + win32-lowercase both sides, no resolve needed when both operands are already absolute) used at every path-valued comparison site, so the installer stops depending on git and Node agreeing on a normalization form — exactly as you proposed. For a regression test, a deterministic pure-string assertion works on any platform: samePath('/tmp/repo/\u00e7', '/tmp/repo/\u0063\u0327') (precomposed vs decomposed ç) — the two strings differ byte-wise but must compare equal.

Your workaround observation (core.precomposeunicode false making install pass) is a nice empirical confirmation that what matters is consistency of form, not which form — NFC normalization removes that dependency entirely.

Thanks again for the precise trace; this one is very reproducible to reason about.

[Jstn-1g]

I implemented and verified a reference fix for this report:

• Reference commit: Jstn-1g@8caefb2
• Reference branch: https://github.com/Jstn-1g/deepseek-harness/tree/reference/discussion-4272-lefthook-unicode-path

The installer now routes config-origin, core.hooksPath, and ownership-marker identity checks through one macOS-aware comparison. On macOS it NFC-normalizes the two spellings Git and the filesystem may return. It deliberately keeps NFC/NFD distinct on other platforms and never resolves direct hook-path values before comparison, so a relative lookalike cannot acquire ownership. Raw string comparison still tracks actual writes for byte-exact rollback.

The deterministic cross-platform regression first reproduced the reported merge-driver-origin failure by modeling NFC Git config output against an NFD checkout path. The fixed suite covers first install, repeat install, marker-backed relocation, exact rollback after a later Lefthook failure, non-macOS separation, and relative-path refusal. Validation passed: focused 5/5; full installer suite 37 passed with 6 platform skips; typecheck, lint, translation pairing, doc-sync 28/28, diff integrity, pre-commit, and the pre-push host build/typecheck.