You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* fix: add-on auth-error guidance + webhook proxy diagnosability (#1694)
#1694 reported authentication failures on a Home Assistant add-on install.
The reported errors and logs aren't internally consistent (the add-on log
shows the WebSocket authenticating then disconnecting; home-assistant.log
shows "invalid authentication from localhost" on /api/websocket plus an
InsecureKeyLengthWarning), and the cause was never reproduced or confirmed.
This does not claim to fix that — it makes the failure class easier to
diagnose and report, and folds in webhook-proxy diagnosability items raised
in the same thread.
- errors.py: on add-on installs only (SUPERVISOR_TOKEN present),
create_auth_error drops the HOMEASSISTANT_TOKEN / long-lived-token
suggestions (no such token under Supervisor auth) for add-on-appropriate
guidance. stdio/pip/Docker installs unchanged. Asserts no cause.
- ha_report_issue: capture home-assistant.log in the bug report (over the
REST/Supervisor path, through the existing secret-sanitizer). The decisive
lines only surface there, not in the add-on container log.
- webhook proxy: mirror inbound-request debug lines into the add-on's own log
(capped /config/.mcp_proxy_inbound.log, tailed by the add-on, fire-and-forget).
- webhook proxy: handle SIGTERM/SIGINT so a Supervisor stop logs why it exited
and runs cleanup (previously skipped — the process was killed mid-loop).
- webhook proxy: append a "fully restart Home Assistant" hint to every error
the proxy returns, including the browser "invalid client_id" OAuth page —
OAuth/webhook registration only refreshes on a full HA restart.
- DOCS + site FAQ: document that reinstalling the add-on regenerates the
webhook URL (wipes /data, overwrites the config) and that toggling OAuth or
regenerating credentials needs a full HA restart; recreate the Claude.ai
connector when the URL or OAuth changes.
- Bump webhook proxy 1.2.0 -> 1.2.1.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* refactor: address review feedback on #1694 webhook-proxy changes
Toolkit + Gemini review of #1700:
- Serialize inbound-mirror writes with a threading.Lock — the cap's
read-modify-write trim could interleave under HA's executor pool
(Gemini + silent-failure-hunter + code-reviewer).
- Reset the stored tail offset on truncation so a newline-less truncated
mirror isn't re-read from 0 every poll (Gemini).
- Guard the initial tail-offset stat() so a permission error / racing delete
can't crash startup (Gemini).
- Extract _install_shutdown_handlers / _shutdown_cleanup / _initial_tail_offset
from main(); cleanup now restores default signal handling first so a second
signal can't abort it. Add unit coverage for the SIGTERM -> cleanup contract
and the webhook 502/500 restart-hint (pr-test-analyzer + code-reviewer).
- Add a negative test that an empty core error log omits the report section.
- Scope the "needs full HA restart" comments to the OAuth HTTP views (the
webhook itself is re-registered on reload), and soften the add-on auth
suggestion + error-log docstring so they don't assert an unconfirmed cause
(comment-analyzer).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* test: cover core_error_log in the in-addon ha_report_issue e2e
The real-Supervisor e2e (TestBugReportAddonLogsReal) asserted addon_logs but
not the sibling core_error_log field this PR adds. Add the parallel assertion
so the #1694 home-assistant.log capture is exercised end-to-end over the real
Supervisor-routed get_error_log path, not only in mocked unit tests.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* test: bump container/haos skip ceilings for the new inaddon e2e
The new TestBugReportAddonLogsReal.test_core_error_log_in_report is
@inaddon_only (module-level pytestmark), so it skips on the container and
external-haos lanes and runs only on haos_inaddon — same shape as the
read-only inaddon test master just added. Bump both ceilings by one so the
skip-count guard in test_session_skipped_count_below_ceiling stays green.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* refactor: scope the restart hint to OAuth registration errors (patch76 review)
A full HA restart only unsticks the stale-OAuth-registration case, so the hint
no longer goes on client-side protocol errors (invalid_grant / invalid_request
/ unsupported_grant_type) or the webhook 502/500 paths — only on invalid_client
and the browser "invalid client_id" page, via a restart_hint flag on
_text_error / _json_error.
Side effect: __init__.py's 502/500 no longer need RESTART_HINT, so it is now
single-sourced in oauth.py — eliminating the cross-file duplication patch76
flagged (and dropping its drift-guard test).
Also tighten the DOCS/FAQ/CHANGELOG "can't re-register on reload" wording: only
the OAuth HTTP views need the full restart; the webhook itself re-registers on
reload.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: kingpanther13 <kingpanther13@users.noreply.github.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: homeassistant-addon-webhook-proxy/DOCS.md
+29-2Lines changed: 29 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,6 +31,16 @@ This addon enables remote access to your HA MCP Server through any reverse proxy
31
31
32
32
> **Reachability check:** Claude.ai connects from Anthropic's servers, not from your computer — so the URL must be reachable from the public internet, not just your LAN. If a connection won't establish, open the remote URL on your **phone with Wi-Fi turned off** (cellular only). If it doesn't load there, the URL isn't publicly reachable (a DNS, port-forward, TLS, or reverse-proxy problem) and Claude.ai can't reach it either — fix that first.
33
33
34
+
> **Recreate the connector when OAuth or the URL changes.** Claude.ai binds an
35
+
> authentication mode to a connector when you add it, and caches it. If you
36
+
> later **turn OAuth on or off**, or the **webhook URL changes** (you rotated
37
+
> it, or reinstalled the addon — which generates a new URL), the existing
38
+
> connector keeps using the old mode/URL and tool calls fail (often
39
+
> `invalid client id` on the consent page, or a silently dead endpoint).
40
+
> **Delete the connector in Claude.ai and add a fresh one** with the current
41
+
> URL (and current OAuth Client ID/Secret, if OAuth is on). This is required
42
+
> even when going from OAuth on → off.
43
+
34
44
> **Note:** If something doesn't seem to work after restarting HA, try restarting the addon as well.
35
45
36
46
## Configuration
@@ -181,7 +191,7 @@ What stops an attacker who can reach the consent page from gaining access:
181
191
182
192
If a client (e.g. Claude.ai) can't connect and you can't tell whether its requests are even reaching Home Assistant, turn on **Log inbound requests** (the `debug_logging` option on the main Configuration page) and **restart the addon**.
183
193
184
-
When it's on, every request that hits the webhook is logged to the **Home Assistant log**— *not* this addon's log, because requests reach Home Assistant directly rather than passing through the addon process. View them at **Settings → System → Logs** (or filter for `mcp_proxy`). Each line shows the method, a masked webhook path, the source address, whether an `Authorization` header was present, and the upstream response status:
194
+
When it's on, every request that hits the webhook is logged to the **Home Assistant log**(requests reach Home Assistant directly rather than passing through the addon process). View them at **Settings → System → Logs** (or filter for `mcp_proxy`). The same lines are also **mirrored into this addon's own log**, so you can watch them on the addon's Log tab without leaving the addon page. Each line shows the method, a masked webhook path, the source address, whether an `Authorization` header was present, and the upstream response status:
185
195
186
196
```
187
197
MCP Proxy [inbound]: POST /api/webhook/mcp_3e... from 203.0.113.4 (Authorization header: present)
@@ -230,6 +240,21 @@ If the `mcp_proxy` integration doesn't appear in Settings > Devices & Services:
230
240
1. Restart Home Assistant (Settings > System > Restart)
231
241
2. The addon will start automatically and retry setup
232
242
243
+
### Persistent errors, especially OAuth "Invalid client id"
244
+
245
+
If the proxy keeps returning the same error — most notably **"Invalid client id"**
246
+
on the OAuth consent page even though you pasted the correct Client ID — **fully
247
+
restart Home Assistant** (Settings → System → Restart).
248
+
249
+
The OAuth provider's HTTP views are bound into Home Assistant's HTTP layer when the
250
+
integration first loads, and Home Assistant can't re-register or drop them on a
251
+
config reload. So changes that come from **toggling OAuth on/off, regenerating
252
+
credentials, or reinstalling the add-on** don't take effect until a full HA
253
+
restart — *reloading the integration or restarting the add-on is not enough.* (The
254
+
webhook endpoint itself is re-registered on every reload, so it's specifically the
255
+
OAuth views that need the restart.) After the restart, re-add the Claude.ai
256
+
connector with the current URL (and current Client ID/Secret, if OAuth is on).
257
+
233
258
### Claude.ai says "Couldn't reach the MCP server"
234
259
235
260
Two cases:
@@ -242,10 +267,12 @@ Two cases:
242
267
## Disabling / Uninstalling
243
268
244
269
-**Stopping** the addon is safe — the webhook URL stays the same and resumes working when the addon is restarted
270
+
-**Reinstalling** the addon always changes the webhook URL. Uninstalling wipes the addon's `/data` (where `webhook_id.txt` is stored), so the next start generates a fresh webhook id and overwrites `/config/.mcp_proxy_config.json` with it. Update your MCP client (and re-add the Claude.ai connector) with the new URL afterwards.
245
271
-**Uninstalling** the addon does not automatically remove the custom integration files. To fully clean up after uninstalling:
246
272
1. Delete `/config/custom_components/mcp_proxy/`
247
273
2. Delete `/config/.mcp_proxy_config.json`
248
-
3. Restart Home Assistant
274
+
3. Delete `/config/.mcp_proxy_inbound.log` (only present if you used **Log inbound requests**; normally removed when the addon stops)
0 commit comments