fix: add timeouts to IPC operations to prevent shell hook hangs

[jdx]

Fixes #26

Summary

The shell hook (pitchfork cd) could hang indefinitely if the IPC connection had issues, causing shell startup to freeze on macOS 15.4 and potentially other systems.

Root Cause

The request() method had an infinite loop waiting for IPC responses with no timeout:

async fn request(&self, msg: IpcRequest) -> Result<IpcResponse> {
    self.send(msg).await?;
    loop {
        if let Some(msg) = self.read().await {
            return Ok(msg);
        }
    }
}

If read() returned None or blocked indefinitely, the shell hook would hang forever.

Changes

• Add 5 second timeout to IPC request/response operations (sufficient for quick operations)
• Add timeout to read operations with proper error handling
• Use dynamic timeout for daemon start based on ready_delay config
• Remove infinite loop that could hang forever
• Return proper Result errors instead of Option for better diagnostics

Test plan

• cargo build passes
• cargo clippy -- -D warnings passes
• cargo test passes (34 tests)
• Manual testing with shell activation on macOS

🤖 Generated with Claude Code

---

Note

Adds bounded waits and better error propagation to IPC.

• Introduces REQUEST_TIMEOUT (5s) and read(timeout) with tokio::time::timeout, returning Result on errors/timeouts
• Replaces infinite wait loop with request_with_timeout(...) used by request(...)
• run(...) now uses a longer timeout derived from ready_delay + 60s for daemon startup
• Improves diagnostics: connection-closed and deserialization errors now surface as structured Result errors

^{Written by Cursor Bugbot for commit cc66765. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[cursor]

Timeout calculation ignores retry backoff time

Medium Severity

The run method timeout calculation opts.ready_delay.unwrap_or(3) + 60 only accounts for a single ready_delay period. When retry > 0 is configured, the server-side run performs multiple attempts with exponential backoff between failures. The total server time can be (retry + 1) × ready_delay + (2^retry - 1) seconds, which can exceed the client timeout. For instance, retry = 5 and ready_delay = 10 yields ~91 seconds server-side but only 70 seconds client timeout, causing spurious timeout errors before the server completes.