Windows named-pipe IPC unreachable when username contains an apostrophe

[zzflgy2009]

Summary

On Windows, when the OS username contains an apostrophe (', e.g. C:\Users\z'z'f'l'g'y), the bsk CLI can never reach the daemon over its named-pipe IPC, even though the daemon logs that it is listening. The daemon-side pipe name generation appears to diverge from the CLI-side name, causing ERROR_PATH_NOT_FOUND (os error 2) on the client.

Environment

• OS: Windows (x86_64)
• Shell: Git Bash and PowerShell (both reproduce)
• browser-skill CLI: bsk 0.1.10 (also reproduced on 0.1.7)
• Username: z'z'f'l'g'y (contains apostrophes)
• Chrome extension: installed and connecting (WS channel works)

Symptoms

1. bsk status / bsk doctor / bsk daemon start hang indefinitely (never return, no timeout), OR return:

   FAIL  daemon running   pid <X> is alive but IPC is unreachable:
   connect IPC named pipe \\.\pipe\bsk-daemon-z'z'f'l'g'y-<hash>: 系统找不到指定的文件 (os error 2)
   

2. Daemon starts successfully every time — logs show:

   daemon ready        pid <X> ws_port 52800 sock \\.\pipe\bsk-daemon-z'z'f'l'g'y-<hash>
   ipc named-pipe server listening pipe \\.\pipe\bsk-daemon-z'z'f'l'g'y-<hash>
   

3. Chrome extension connects to the daemon over WS (browser connected id=... name=chrome) — only the CLI↔daemon IPC channel fails.
4. bsk --version works (does not touch the daemon).
5. Daemon dies after a few minutes (secondary symptom — caused by repeated CLI start attempts / timeout killing the child process).

Key evidence (root cause)

• The CLI constructs the pipe name correctly (verified under PowerShell where no MSYS path munging occurs): it tries to connect \\.\pipe\bsk-daemon-z'z'f'l'g'y-534cdbb77f0321fc.
• The OS reports os error 2 (ERROR_PATH_NOT_FOUND) — the pipe with that exact name does not exist.
• Yet the daemon log claims it is listening on that exact name.

→ The daemon-side pipe name (what is actually created) diverges from the CLI-side name when the username contains an apostrophe. This is consistent with a named-pipe name generation/escaping bug triggered by the ' character.

Repro steps

On a Windows machine whose username contains an apostrophe:

bsk doctor            # daemon running FAIL: pid alive but IPC unreachable
bsk daemon start      # hangs; daemon actually starts (see ~/.bsk/daemon.log.2026-08-09)

Optional verification that the pipe is genuinely missing:

import ctypes
k32 = ctypes.windll.kernel32
name = r"\\.\pipe\bsk-daemon-z'z'f'l'g'y-534cdbb77f0321fc"  # from daemon.json / log
h = k32.CreateFileW(name, 0x80000000, 0, None, 3, 0, None)
print("OK" if h not in (-1, 0) else f"FAIL err={k32.GetLastError()}")  # err=3 = path not found

Expected behavior

CLI should be able to connect to the daemon's named pipe regardless of the username's characters. Either:

• the daemon creates the pipe under the same name the CLI looks up (fix name generation/escaping for '), or
• fall back to a pipe name that avoids the username entirely (e.g. hash-only).

Workaround (confirmed)

• A username without special characters is expected to work (not yet verified by us — we cannot change the OS user).
• Everything else in the toolchain is healthy: CLI, skill install, Chrome extension, daemon startup, WS browser channel.

Logs (relevant excerpt)

{"message":"daemon ready","pid":36272,"ws_port":52800,"sock":"\\\\.\\pipe\\bsk-daemon-z'z'f'l'g'y-534cdbb77f0321fc"}
{"message":"ipc named-pipe server listening","pipe":"\\\\.\\pipe\\bsk-daemon-z'z'f'l'g'y-534cdbb77f0321fc"}
{"message":"browser connected","id":"2ebcec26","name":"chrome","generation":1}

CLI side (PowerShell, no MSYS interference):

error: could not verify daemon identity for pid 52860; refusing to stop:
connect IPC named pipe \\.\pipe\bsk-daemon-z'z'f'l'g'y-534cdbb77f0321fc: 系统找不到指定的文件 (os error 2)

[iuyo5678]

This is a simple issue, can you submit a pull request and fix it? @zzflgy2009

[BB-fat]

Thanks for the excellent detective work in this issue — the evidence you collected (daemon alive and "listening", yet CreateFileW on the same name returning FILE_NOT_FOUND, verified from PowerShell) made the root cause much easier to pin down. Fix PR: #86.

Root cause. crates/bsk-cli/src/daemon/paths.rs embedded %USERNAME% verbatim in the pipe name (\\.\pipe\bsk-daemon-{user}-{hash}). Both sides were verified to use byte-identical names (the CLI reads the name from daemon.json and never recomputes it), so the divergence is at the Win32/NPFS boundary: with apostrophes in the name, CreateNamedPipeW succeeds while opening the same name fails — despite the docs saying any non-backslash character is legal.

A secondary finding that explains the "commands hang / daemon dies after a few minutes" symptoms: when IPC verification fails, ensure_daemon keeps spawning fresh daemons, and each new one immediately exits because the previous daemon still holds daemon.lock — so every command re-attempts a doomed daemon startup.

Fix. #86 makes the pipe name hash-only (\\.\pipe\bsk-daemon-{hash}). The hash already covers user + home, so uniqueness/isolation are unchanged, but no raw username characters ever reach NPFS. Unit tests pin the output charset against apostrophe/space/Unicode usernames. Since the name is only ever exchanged via daemon.json, old/new CLI and daemon builds interoperate freely.

Verification. CI is green, but GitHub Actions only runs Ubuntu here — the NPFS behaviour itself needs a real Windows machine. Could you try the build from the PR branch (fix/75-pipe-name-sanitize) and confirm bsk doctor / bsk daemon start work on your machine?