chenhg5/cc-connect · critical

start: %w

Error message

start: %w

What it means

agent/pi/session.go:210 — startRPC fails to spawn the persistent `pi --mode rpc` child process via cmd.Start() and wraps the OS/exec error with "start: %w". This error is returned synchronously to newPiSession, so session creation fails outright and no RPC session is created. It means the pi binary could not be executed at all (not found, not executable, or exec-level failure), not that pi crashed later.

Source

Thrown at agent/pi/session.go:210

	cmd.Env = env

	stdinPipe, err := cmd.StdinPipe()
	if err != nil {
		return fmt.Errorf("stdin pipe: %w", err)
	}
	s.rpcStdin = stdinPipe
	s.rpcCmd = cmd

	stdout, err := cmd.StdoutPipe()
	if err != nil {
		return fmt.Errorf("stdout pipe: %w", err)
	}
	cmd.Stderr = &s.stderrBuf

	prepareCmdForKill(cmd)

	if err := cmd.Start(); err != nil {
		return fmt.Errorf("start: %w", err)
	}

	s.wg.Add(1)
	go s.readLoopRPC(stdout)

	// Pi's RPC protocol does not push a "session" event on stdout — the only
	// way to learn the session id is to send {"type":"get_state"} and parse
	// the matching response in handleEvent. We probe immediately after spawn
	// so that newPiSession's wait on rpcReady only unblocks once the id has
	// been stored. readLoopRPC closes rpcReady as soon as sessionIDReady()
	// flips to true (which happens after handleEvent processes the response),
	// so callers can safely read CurrentSessionID() the moment rpcReady fires.
	//
	// If the probe write fails, the session is unrecoverable: without the
	// session id we cannot resume after /stop, which is the very bug we are
	// fixing. Bail out immediately and let the caller surface the error
	// instead of waiting for the 30s rpcReady timeout.
	if err := s.writeRPCCommand(map[string]any{

View on GitHub (pinned to 4000b2338a)

Solutions

1. Verify the configured pi binary exists and is executable: `which <cmd>` and `ls -l $(which <cmd>)`; install pi or fix the `cmd` value in config.toml to an absolute path.
2. Check that the session's workDir exists and is accessible by the user running cc-connect.
3. Run the exact command the agent would run (`pi --mode rpc`) manually in the configured workDir to reproduce the exec failure outside the daemon.
4. If running under systemd/Docker, fix PATH or binary permissions for the service user.

Example fix

// config.toml
# before
[agents.pi]
cmd = "pi"          # not on daemon PATH
# after
[agents.pi]
cmd = "/usr/local/bin/pi"

bin := agentConfig.Cmd
if p, err := exec.LookPath(bin); err != nil {
    return fmt.Errorf("pi binary %q not found: %w", bin, err)
} else if fi, err := os.Stat(p); err != nil || fi.Mode()&0o111 == 0 {
    return fmt.Errorf("pi binary %q is not executable", p)
}
if _, err := os.Stat(workDir); err != nil {
    return fmt.Errorf("workDir %q unavailable: %w", workDir, err)
}

When it happens

Trigger: Calling core.CreateAgent("pi",...) / newPiSession with rpc mode enabled when: (1) the configured `cmd` binary does not exist on PATH; (2) the file exists but lacks the executable bit; (3) exec fails due to resource limits (fork/exec ENOMEM, EAGAIN); (4) workDir (cmd.Dir) no longer exists.

Common situations: pi CLI not installed or installed under a different name than configured; config.toml points `cmd` at a relative path while the daemon's working directory differs; user upgraded the binary and permissions changed; Docker/systemd unit with a restricted PATH missing the pi install location.

Related errors

• pi: start rpc: %w
• acp: probe start %s: %w
• antigravitySession: start: %w
• claudeSession: stdin pipe: %w
• claudeSession: stdout pipe: %w

AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06). Data as JSON: /api/errors/c389b923cc5f7337. Report an issue: GitHub.