app

Adom Bridge

Public Made by Adom

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

adom-bridgetauriclaude-codebridgekicadfusion360puppeteerdesktop-automation
Overview Files Skills Discover Packages Releases Dependencies Issues19 Breadcrumbs Pull Requests1 Activity
Closed general

Direct-API CLI call ignores the bridge's declared per-verb timeout (120 s default cuts a 1500 s verb) and then reports 'Cannot reach relay server' locally

Drew Owens · 26d ago ·closed by John Lauer

What happened (reported by a community user on adom/solidworks-bridge#2, 2026-10-15; ab 2.1.168, Windows 11, bridge solidworks 0.10.9)

adom-bridge-cli swx_selftest '{"level":"write"}' over the direct API (no responseMode) returned after durationMs: 122097 — the CLI's 120 s default — although the bridge's refreshed bridge.json declares a per-verb budget "selftest": 1500. The verb itself takes 5-8 minutes. Two consequences:

  1. The run was cut off after creating its first scratch document; nothing further ran, and the bridge's ledger shows nothing after that point (the request simply vanished for the bridge).
  2. The CLI then reported "status": "busy" with "Cannot reach relay server (port 8766)" — misleading, because the direct API on 24680 was up the whole time and the call was local.

Re-running with responseMode: "stream" completed normally in 440 s.

Expected

  • The CLI (and the direct-API path) honour the verb's declared timeout from the bridge's bridge.json (timeouts/per-verb budgets), the same registry timeouts reports for the relay path, so a long verb is not cut at 120 s by default.
  • When a call does exceed the client budget, the status must say that ("the client stopped waiting after 120 s; the verb may still be running — poll <statusVerb> or re-run with responseMode: job"), never "Cannot reach relay server" on a local direct-API call.

The bridge side is being hardened too (its _timeoutHint now leads with the responseMode advice, and an abandoned self-test will clean up its own scratch documents), but the default budget and the message belong to ab.

1 Reply

John Lauer · 26d ago

Fixed in 2.1.184 (insiders). The cause was on the ab side, in two places:

  1. The local API waited a fixed 120 s for every bridge verb and never read the bridge's timeouts, so swx_selftest (declared 1500 s) was cut off while the bridge kept working.
  2. The CLI treated that 504 as "ab unreachable" and re-sent the call to a relay. With no local relay that printed "Cannot reach relay server (port 8766)"; with one, it could have run the verb twice.

Now the local API waits for the claiming bridge's declared budget plus 15 s (never less than the CLI's own budget, capped at 30 min). If a wait still runs out, the reply is errorCode: timed_out with stillRunning: true, the bridge's statusVerb, and a hint to poll it or use responseMode: "job". The CLI returns that reply and never re-sends a call the local ab already took. responseMode: "stream" / "job" remains the right choice for multi-minute verbs.

John Lauer closed this · 26d ago

Log in to reply.