What causes "SyncRpcChannel: timed out connecting to named pipe" in microsoft/typescript-go?

Retry the Client construction once — transient startup slowness often passes on a warm cache

SyncRpcChannel: timed out connecting to named pipe

Error message

SyncRpcChannel: timed out connecting to named pipe

What it means

After 500 openSync retries (about 5 seconds) on Windows, if the named pipe still does not exist and the child has not exited, the channel kills the child and throws this timeout. It means the server started but never (or not yet) created its pipe: an extremely slow start, a blocked startup, or pipe creation being prevented by external software.

Source

Thrown at _packages/native-preview/src/api/syncChannel.ts:173

            // Retry openSync until the child creates the named pipe.
            let fd: number | undefined;
            for (let i = 0; i < 500; i++) {
                try {
                    fd = openSync(pipePath, "r+");
                    break;
                }
                catch {
                    if (this.child.exitCode !== null) {
                        throw new Error(
                            `Child process exited with code ${this.child.exitCode} before pipe was ready`,
                        );
                    }
                    Atomics.wait(sleepBuf, 0, 0, 10);
                }
            }
            if (fd === undefined) {
                this.child.kill();
                throw new Error("SyncRpcChannel: timed out connecting to named pipe");
            }
            this.readFd = fd;
            this.writeFd = fd;
            this.pipeFd = fd;
        }
        else {
            // POSIX: use stdio pipe file descriptors directly.
            this.child = spawn(exe, args, {
                stdio: ["pipe", "pipe", "inherit"],
            });

            const stdout = this.child.stdout! as StdoutWithHandle;
            const stdin = this.child.stdin! as StdinWithHandle;

            this.readFd = stdout._handle.fd;
            this.writeFd = stdin._handle.fd;

            if (typeof this.readFd !== "number" || this.readFd < 0 || typeof this.writeFd !== "number" || this.writeFd < 0) {

View on GitHub (pinned to 1bcfa18d79)

Solutions

Retry the Client construction once — transient startup slowness often passes on a warm cache
Exclude the tsgo binary from antivirus/EDR scanning, or run where named pipes are permitted
Verify the child can create pipes at all on the machine (e.g. run the binary manually and look for the pipe)

Defensive patterns

Strategy: retry

Try / catch

try { api = new API({ cwd }); } catch (e) { if ((e as Error).message.includes("timed out connecting")) { api = new API({ cwd }); /* one warm retry */ } else throw e; }

Prevention

Warm the machine/binary before latency-sensitive startup (first run is slowest)
Exclude the tsgo binary from antivirus scanning on Windows
Retry once on this specific timeout; persistent failures indicate a blocked pipe environment

When it happens

Trigger: Thrown at _packages/native-preview/src/api/syncChannel.ts:173 when the library encounters an invalid state.

Common situations: Corporate antivirus quarantining or delaying the spawned binary; CI runners with severe CPU contention; first-run signature scans delaying the child for seconds.

Understand the failure class

Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

AI-assisted analysis of microsoft/typescript-go@1bcfa18d79 (2026-08-16). Data as JSON: /api/errors/5d6f1f885083ed79. Report an issue: GitHub.