CLI kicad passthrough: flat 30s timeout undercuts AD's 130s bridge budget (false timeouts on cold open)

by adom

Adom Bridge unleashes your AI onto your full PC: full power, full safety. The AI breaks out of the container it runs in and onto your real machine, managing and running your entire laptop as you: launch apps, move files, drive any window, control KiCad, Fusion 360 or your real signed-in browser. Works with any AI, cloud or local (Claude Desktop, Claude Code, Codex), no Hydrogen required. Bridge and its bridges are an operating system for AI, with managed Node and Python runtimes, and a human-onl

Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity

Closed general

Kyle Bergstedt · 3mo ago ·closed by John Lauer

Found via a live container session on 2026-08-12. cli/src/commands.rs's kicad_* passthrough arm calls relay::desktop_command with a flat 30000 ms, but AD core's kicad bridge budget (timeout_meta::builtin_timeout_secs) is 130s. A cold kicad_open_board launches the whole KiCad app (35-60s), so the CLI times out with the generic 'desktop didn't respond' hint while the operation actually succeeds — and the caller never receives AD's rich timed_out/stillRunning/statusVerb response because the CLI bails first. Same false timeout on kicad_window_info during app startup. Fix: raise the CLI-side kicad budget above AD's (the macOS line shipped 140_000 ms in 1.9.189). Rule of thumb worth encoding: a CLI inline budget must always exceed the AD-side budget for that namespace, or the timeout_meta contract never reaches the caller.

1 Reply

John Lauer · 2mo ago

Fixed in 2.0.41. The CLI kicad passthrough budget is raised 30s -> 140s (above AD-core's 130s kicad bridge budget), so a cold KiCad launch no longer false-times-out before AD's rich timed_out/stillRunning/statusVerb response reaches the caller. Rule encoded in-code: a CLI inline budget must exceed the AD-side budget for that namespace. Closing.

John Lauer closed this · 2mo ago