A non-ASCII character in a verb's reason fails every bridge call before it is sent (header encoding)

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

Drew Owens · 28d ago ·closed by John Lauer

What happens (measured 2026-10-13, ab 2.1.174 on Windows 11, bridge `solidworks` 0.10.1)

Any bridge verb whose reason argument contains a non-ASCII character fails before it reaches the bridge, in about 200 ms:

Bridge 'solidworks' HTTP error: error sending request for url (http://127.0.0.1:49861/command)

Minimal repro, a read-only verb:

adom-bridge --target <box> --ai-thread "t" swx_status '{"reason":"read-only check — em dash"}'   # fails as above
adom-bridge --target <box> --ai-thread "t" swx_status '{"reason":"read-only check - hyphen"}'    # ok

The same swx_sign_in call failed three times with an em dash in its reason and succeeded with the em dash replaced by a semicolon. The bridge process never saw the requests: it did not restart, and its own verb-panic guard (which turns panics into JSON errors) never fired.

Likely cause

ab appears to forward the caller's reason to the bridge as an HTTP header (for example an X-Adom-Caller-* header). HTTP header values must be visible ASCII, and reqwest's HeaderValue::from_str rejects anything else, so building the request fails and reqwest reports "error sending request".

Why it matters

The reason is free text written by people and AIs. Typographic dashes, curly quotes, accented names (our first community user is Michael; the next may be François), and non-Latin scripts are normal input, and every verb fails on them with an error that points at the bridge.

Suggested fix

Encode the forwarded reason (percent-encoding or RFC 8187 UTF-8''…, or base64 in a -b64 variant of the header), or carry it in the request body instead of a header. At minimum, replace characters a header cannot carry instead of failing the whole call, and say so in the reply. The verb's own args.reason already travels intact in the JSON body.

1 Reply

John Lauer · 26d ago

Fixed in 2.1.175 (insiders).

Cause: your diagnosis was right. Adom Bridge forwarded the caller's thread, container and reason to the bridge as X-Adom-Caller-* headers, and a header value that isn't visible ASCII made reqwest fail the whole request before it was sent.

Fix:

The plain header now always carries an ASCII rendering: dashes become -, curly quotes become straight quotes, and anything else becomes ?.
When that loses information, the exact text rides alongside in X-Adom-Caller-<Name>-UTF8, percent-encoded UTF-8. A bridge that wants the exact text decodes that header.
Adom Bridge's own reader prefers it, so the Activity Log and onward calls keep "François" intact.
The verb's own args.reason in the body was never affected.

Checked live on arav-rog (2.1.175): kicad_status with reason read-only check — em dash, “quotes”, François and thread name ab-175 François returned success:true over the mesh. That's the exact call shape that failed for you.

John Lauer closed this · 26d ago

Adom Bridge