fix: route addon and HA core log fetches directly to Supervisor on addon installs

[Patch76]

What does this PR do?

Closes #1116. On add-on installs, ha_get_logs(source="supervisor", slug=...) returns 403 for every slug because HA Core rejects the SUPERVISOR_TOKEN against the proxy route /api/hassio/addons/{slug}/logs. Route around HA Core entirely on add-on installs by hitting the documented Supervisor REST API at http://supervisor/addons/{slug}/logs directly with the Supervisor token — same access pattern tools_bug_report.py:_fetch_addon_logs already uses for self-logs.

The HA-Core-proxy path stays as the fallback for non-addon installs (Docker, pyinstaller, pip pointing at a normal HA URL with admin LLA), where it continues to work fine. The bug only manifests on the addon-container call against http://supervisor/core.

Branching gate is the existing is_running_in_addon() helper in src/ha_mcp/_version.py — no fourth duplicate of the SUPERVISOR_TOKEN env-var check.

Companion config change — hassio_role: default → manager

KP13 verified locally that the Supervisor token does not grant /addons/{slug}/logs (or /{service}/logs) access on the default role. Bumped to manager in both homeassistant-addon/config.yaml and homeassistant-addon-dev/config.yaml, with an inline comment citing the live test.

Scope addition — source="system_service"

KP13's PR-comment 12:42 surfaced that #1116 also covers the missing-feature case: HA-Supervisor-managed system service logs (/supervisor/logs, /host/logs, /core/logs, /dns/logs, /audio/logs, /multicast/logs, /observer/logs) were not reachable via any source value. Added a new source="system_service" value matching KP13's data-type-named source convention (#911 / #1003).

• New slug semantics for source="system_service": a service name from SYSTEM_SERVICE_SLUGS = {supervisor, host, core, dns, audio, multicast, observer}. Caller-layer enum validation gives users the allowed set before the request fires.
• Slug namespace overlap is acceptable because the source parameter disambiguates: slug="supervisor" under source="system_service" means the Supervisor service's own logs, not an add-on with that name. Docstring lists both slug semantics separately.
• New REST-client method _get_system_service_logs(service) extracted to a shared _supervisor_logs_get(path) helper alongside _get_addon_logs_via_supervisor; both branches now share error handling, JSON-envelope parsing, role-hint 403 messaging, and the fail-fast empty-token guard.

KP13 CR disposition (16 of 17 adopted)

#	Item	Disposition
1	Empty SUPERVISOR_TOKEN silent blank Bearer	✅ Fail-fast HomeAssistantAuthError with distinct "absent at call time" message
2	403 not mapped distinctly	✅ Carved out before generic >=400 with role-hint suggestion
3	Stale _get_supervisor_log docstring	✅ Boy-Scout: dropped #950-only framing, describes branch-on-is_running_in_addon()
4	Misleading "mirrors _fetch_addon_logs" framing	✅ Rewritten to enumerate scope (arbitrary slug vs self) + role (manager vs default) differences
5	verify_ssl no-op for http://supervisor	✅ Kept with explicit symmetry comment citing #1128's 3-site convention (KP13's option B)
6	Error envelope JSON not parsed	✅ json.loads(text_body).get("message") first, then text/reason_phrase fallback
7	Catch-order timeout vs HTTPError no observable diff	✅ Distinct "Timeout..." / "Transport error..." messages
8	level param applies to source="supervisor"	📝 Already emitted at tools_utility.py:139 — supervisor is in the level-not-applicable warning tuple, pinned by test_level_param_emits_warning_for_supervisor_source. PR adds system_service to the same tuple + parallel test for parity
9	No logger.warning on >=400 raise path	✅ Logged with status + path before every 4xx raise
10	Missing/empty SUPERVISOR_TOKEN test	✅ test_raises_auth_error_on_empty_supervisor_token + parallel for system_service
11	Generic httpx.HTTPError untested	✅ test_raises_connection_error_on_remote_protocol_error
12	Tier-3 reason-phrase fallback parity	✅ test_empty_body_no_reason_phrase_uses_placeholder
13	ctor-kwargs propagation untested	✅ verify + timeout asserted on the URL+auth happy-path test
14	test_addon_install_uses_supervisor_direct mock-the-mock	✅ Shrunk to gate-only check; URL/auth contract delegated to dedicated class
15	Patch path brittleness	✅ Migrated to patch("httpx.AsyncClient", ...) — robust to either import httpx or from httpx import AsyncClient
16	Inaccurate gate description	✅ Docstring says is_running_in_addon(), not "SUPERVISOR_TOKEN env present"
17	Drop redundant narration	✅ Per-test/fixture/class-level docstrings trimmed

Test coverage

File	Class	What it pins
tests/src/unit/test_tools_utility_supervisor_logs.py	TestGetAddonLogsViaSupervisor (extended)	URL+auth+ctor-kwargs, 401/403/404/JSON-envelope/empty-body+reason/empty-body-no-reason, timeout vs transport distinct messages, RemoteProtocolError, empty-token fail-fast
	TestGetSystemServiceLogs (new)	Service URL+auth+ctor-kwargs, empty-token fail-fast, 403 role-hint, 404
	TestGetSystemServiceLogWrapper (new)	Response shape, missing-slug validation, invalid-slug enum hint, all-7-services dispatch (parametrized), 403 role-hint suggestion, level-warning parity
	TestGetAddonLogsBranchSelection (modified)	Gate-only check after #14 shrink

Local: 1703 unit tests pass, ruff clean, mypy clean.

Out of scope

The issue body asks for an integration/contract test against a real Supervisor-equipped HA. The existing E2E suite uses a Supervisor-less homeassistant/home-assistant testcontainer; spinning up a Supervisor side-car is outside this PR. Filing as a Suggested Improvement.

Round 3 — error_log + slug warning + role docs (commit a49dbc3)

KP13's round-2 review surfaced three more items addressed in a49dbc3:

• Critical 1: source="error_log" is broken on Supervisor installs — same root cause as [BUG] ha_get_logs(source="supervisor") returns 403 for every slug on add-on installs #1116. HA Core's bootstrap.py:641-651 sets err_log_path = None when the SUPERVISOR env var is present, so hass.data[DATA_LOGGING] is never populated and the APIErrorLog view is not registered (/api/error_log → 404 by-design). Fix shape mirrors get_addon_logs: branch HomeAssistantClient.get_error_log() on is_running_in_addon() → _supervisor_logs_get("core") for the addon branch (HA Core's container log via Supervisor — same content, different transport). Pinned by TestGetErrorLogBranchSelection.
• Nit 2: slug parameter incompatibility warning — third warning in tools_utility.ha_get_logs, parallels the existing level and entity_id/end_time warnings. Pinned by TestSlugParameterIncompatibilityWarning parametrized over four non-supervisor sources (warn) and two supervisor sources (no warn).
• Nit 3: Role escalation undocumented — ### Supervisor Permissions section in homeassistant-addon/DOCS.md, plus ### Permissions subsection in homeassistant-addon-dev/DOCS.md, calling out the hassio_role: manager requirement.

Local: 1711 unit tests pass, ruff clean.

Type of change

• 🐛 Bug fix
• ✨ New feature (system_service source)
• 📚 Documentation
• 🔧 Maintenance/refactor
• 🧪 Tests only
• 💥 Breaking change

Testing

• I have tested these changes with a LLM agent (live bug reproduction on stable v7.4.1; post-merge dev-channel deploy will confirm fix)
• All automated tests pass (uv run pytest)
• Code follows style guidelines (uv run ruff check)

Checklist

• I have updated documentation if needed (no docs touched; bug fix in client layer + new source param documented in tool docstring)

Closes #1116

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves an issue where fetching add-on logs failed in Supervisor-equipped environments due to HA Core proxy restrictions. By introducing a direct communication path to the Supervisor API when running as an add-on, the fix ensures reliable log retrieval while maintaining backward compatibility for non-add-on installations.

Highlights

• Direct Supervisor API Access: Implemented a direct connection to the Supervisor REST API for add-on environments, bypassing the HA Core proxy which was rejecting requests with 403 errors.
• Environment-Aware Routing: Added logic to detect if the application is running within an add-on container, allowing it to dynamically choose between the direct Supervisor path and the existing HA Core proxy fallback.
• Comprehensive Test Coverage: Added new test suites to verify both the direct Supervisor path and the fallback mechanism, ensuring robust error handling and correct branch selection.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[Patch76]

Implementation Summary

Choices Made:

• Direct Supervisor REST API on add-on installs, HA-Core-proxy as fallback for non-addon installs — this is exactly what KP13's issue body suggests. The fix sits in rest_client.py:get_addon_logs and branches on is_running_in_addon().
• Reuse is_running_in_addon() from _version.py:51-58 as the gate. There were already three SUPERVISOR_TOKEN-detection sites in the codebase (_version.py canonical, settings_ui.py:111 local mirror, tools_bug_report.py:67/179); adding a fourth would have been needless duplication.
• Standalone httpx.AsyncClient block (new helper _get_addon_logs_via_supervisor) rather than a header-override on _raw_request. Mirrors the pattern tools_bug_report.py:_fetch_addon_logs already uses (tools_bug_report.py:184-188) — both the base URL (http://supervisor) and the token (SUPERVISOR_TOKEN) differ from HomeAssistantClient.httpx_client's configuration, so a fresh client is the cleaner shape.
• Same exception surface in both branches (HomeAssistantAuthError / HomeAssistantAPIError with status_code / HomeAssistantConnectionError) so the wrapper layer in tools_utility.py:_get_supervisor_log keeps working unchanged regardless of which branch ran.
• Empty-body fallback to reason_phrase in the Supervisor-direct branch — pre-existing pattern from _raw_request (rest_client.py:159-176), preserved for consistency so a 5xx with empty body doesn't surface as "API error: 502 - " with a blank tail.
• Test fixture redesign — split into non_addon_install and addon_install fixtures. The existing TestGetAddonLogs class now uses an autouse _force_non_addon fixture to guarantee the HA-Core-proxy path; otherwise CI environments where SUPERVISOR_TOKEN happens to be set could route the existing tests through the new branch and silently bypass the mock_client.httpx_client mock.

Problems Encountered:

• None during implementation. Issue body had a clear root-cause analysis from KP13, the matching tools_bug_report.py pattern was already in the codebase, and the new tests pinned both branches plus the gate selection. 1682/1682 unit tests pass locally.

Suggested Improvements:

• Real-Supervisor integration test (per the test-coverage-gap ask in the issue body) — out of scope for this PR. The current E2E suite uses a Supervisor-less homeassistant/home-assistant testcontainer and there is no precedent in tests/src/e2e/conftest.py for spinning up a Supervisor side-car. Adding Supervisor-equipped E2E coverage broadly (not just for the addon-logs path) would benefit from a separate maintainer discussion on testcontainer composition and CI cost. Filed as [FEATURE] Add Supervisor-equipped E2E test infrastructure #1129 for tracking — three open architecture questions there (container choice, CI cost budget, test-suite layout).
• HA-Core "regression" investigation — there is no regression. Bisected against home-assistant/core: homeassistant/components/hassio/http.py is byte-identical between 2026.4.0 and 2026.4.4, and the PATHS_ADMIN regex has listed addons/[^/]+/logs(/follow|/boots/-?\d+(/follow)?)? since at least 2025.3.0. The auth gate (is_admin = request[KEY_AUTHENTICATED] and request[KEY_HASS_USER].is_admin in http.py:162-166) has been unchanged across that whole span. The 403 is documented behavior, not a recent break: SUPERVISOR_TOKEN (add-on-issued) does not authenticate as the Core-internal HASSIO_USER admin that PATHS_ADMIN requires — the HA-Core-proxy was never the right path for the add-on-container case. The April 2026 hassio-hardening PRs (#169226, #169299, #169324, #169325, #169329, #169340) all merged to dev 3-4 days after the 2026.4.4 tag, and on inspection none of them touch the PATHS_ADMIN regex or the addons/{slug}/logs auth path — they cover services.py, websocket_api.py, addon_panel.py, discovery.py, and const.py respectively; #169299's http.py change touches only the onboarding-bypass branch, which doesn't apply to onboarded users. The "verified working" phrasing on fix: route supervisor add-on log fetches through HA Core REST proxy #951 must therefore reflect either a different code path (e.g. supervisor/logs) or a non-add-on token context at test time. The fix in this PR is unaffected — it routes around a long-standing access mismatch via the semantically correct token-against-endpoint pairing (Supervisor token against Supervisor itself).

[gemini-code-assist]

Code Review

This pull request implements a direct communication path with the Supervisor REST API for fetching add-on logs when running within a Home Assistant add-on environment, while maintaining the HA Core proxy as a fallback for other installation types. This change resolves issues where the proxy would reject certain token and path combinations. Feedback was provided to ensure that the newly introduced httpx.AsyncClient consistently applies the verify_ssl configuration used elsewhere in the HomeAssistantClient class.

[Patch76]

/gemini review

[gemini-code-assist]

Code Review

This pull request updates the get_addon_logs method in the REST client to support direct communication with the Supervisor API when running within a Home Assistant add-on environment. This change bypasses the HA Core proxy to avoid authentication issues and includes comprehensive unit tests for both the direct and fallback paths. Feedback was provided regarding the efficiency of instantiating a new httpx.AsyncClient for every request, suggesting the use of a persistent client instead.

[Patch76]

/gemini review

[gemini-code-assist]

Code Review

This pull request updates the get_addon_logs method in the REST client to support direct communication with the Supervisor API when running as a Home Assistant add-on. This change bypasses the HA Core proxy, which previously caused authentication issues in certain environments. The update includes a new internal helper method, _get_addon_logs_via_supervisor, and comprehensive unit tests covering success scenarios, error mapping, and branch selection logic. Feedback was provided to ensure docstring consistency by using an action verb in the internal helper's documentation.

[kingpanther13]

When I tested it locally it still isn't working till I bumped the hassio role. So requesting we bump hassio_role: default → manager in both homeassistant-addon/config.yaml and
homeassistant-addon-dev/config.yaml , it'll make this work.

Also I just caught that the tool still doesn't access the actual director supervisor logs (system) like it is intended to do, that was part of the intent of issue #1116 to address that as well
I thought it was the same but but it turns out the tool just doesn't currently have the capability. Will request we add that in ( access to /supervisor/logs, /host/logs, /core/logs, /dns/logs, /audio/logs, /multicast/logs, or /observer/logs. would need a new source (e.g. source="system_service" with a slug enum)) and change hassio role as above. Will do pr review toolkit in a few minutes too with other requested changes, but those are the biggest things just to get this to work in the first place.

[kingpanther13]

In addition to the above comment, please address:

Critical

1. Empty SUPERVISOR_TOKEN silently produces blank Bearer. rest_client.py:482 defaults to "". If the gate ever disagrees with reality (detection bug, dev sideload), Supervisor 401s and the user sees "Invalid Supervisor token" — wrong diagnosis. Fail-fast with a config-error message, or fall through to the proxy branch with a logger.warning.
2. 403 not mapped distinctly. rest_client.py:498-505 lumps the actual #1116 symptom into the generic >= 400 path. Add a 403 branch with a remediation hint (role / addon manifest), since that's the failure mode this PR is most likely to surface during the role rollout.
3. Stale tool docstring. tools_utility.py:622-628 still describes the HA-Core-proxy path and references #950. Boy-Scout — update to describe the new branch-on-is_running_in_addon() behavior.
4. Misleading "mirrors _fetch_addon_logs" framing. rest_client.py:475. That helper is hardcoded to slug=self and works on default role; this helper takes arbitrary slugs and (will) need manager. The docstring should call out the scope/role difference instead of claiming mirroring.

Important
5. verify=self.verify_ssl is a no-op for http://supervisor (rest_client.py:481). Drop it, or add a one-liner comment that it's there for symmetry only.
6. Error envelope not parsed. Supervisor returns {"result":"error","message":"..."} JSON on some 4xx paths. Currently the raw JSON string lands in the user-facing message. Try json.loads(text_body).get("message") first, then fall back to text/reason_phrase.
7. Catch-order split with no observable difference. TimeoutException and HTTPError both raise HomeAssistantConnectionError with near-identical messages. Differentiate ("Timeout..." vs "Transport error...") or collapse to one clause.
8. level param still applies to source="supervisor" (tools_utility.py:139). Meaningless for raw container stdout — now that slug paths actually return content, users will pass level="ERROR" and get nonsense filtering. Drop supervisor from the tuple or warn when both level and slug are set.
9. No logger.warning on the >= 400 raise path in _get_addon_logs_via_supervisor. Operators have to enable debug to diagnose. Log status + slug at warning level on the raise side.

Test gaps
10. Missing/empty SUPERVISOR_TOKEN path untested. Pin behavior either way (fail-fast or "blank Bearer → 401").
11. Generic non-timeout httpx.HTTPError (e.g. RemoteProtocolError) untested. The except httpx.HTTPError clause can be silently narrowed by a future refactor.
12. Tier-3 reason-phrase fallback untested — empty body + empty reason_phrase → "<empty body>". TestRawRequestEmptyBodyFallback covers this for the proxy branch; parity gap for the supervisor branch.
13. verify_ssl + timeout ctor-kwargs propagation untested. mock_async_client_class exposes client_class but no test asserts on client_class.call_args.kwargs. Cheap to add to the happy-path test — a regression that hard-codes verify=True or drops the timeout would currently keep CI green.
14. TestGetAddonLogsBranchSelection::test_addon_install_uses_supervisor_direct is mock-the-mock. Duplicates the URL+auth assertions in the dedicated class without re-asserting them, so the test would pass for any implementation that calls httpx.AsyncClient(...).get(...). Either tighten it to assert URL + Authorization on this path too, or shrink to a one-liner that only verifies the gate was consulted (and explicitly delegates contract to the dedicated class).
15. Patch path brittleness. patch("ha_mcp.client.rest_client.httpx.AsyncClient", ...) works only because httpx is imported as a module. A future from httpx import AsyncClient silently breaks it. Prefer patch("httpx.AsyncClient", ...).

Comment / docstring trims
16. Inaccurate gate description. rest_client.py:441 says "On add-on installs (SUPERVISOR_TOKEN env present)". The gate is is_running_in_addon(), not the env var (token is read separately at line 481 with a "" default). If is_running_in_addon ever stops keying off that env var the docstring lies.
17. Drop redundant narration:
- _force_non_addon fixture docstring restates the decorator.
- mock_async_client_class docstring narrates the `async with` mocking pattern (implementation detail).
- Per-test docstrings ("The fix's primary contract...", "401 from Supervisor maps to...") restate test names — drop or trim.
- TestGetAddonLogsViaSupervisor class docstring duplicates the _get_addon_logs_via_supervisor production-code #1116 narrative — keep one copy in the production code.

[Patch76]

Implementation Summary

Round 2 of CR addressing — full 17-item disposition table is in the PR body (just refreshed).

Choices Made:

• Shared _supervisor_logs_get(path) helper in rest_client.py so addon-logs and system-service logs share the empty-token fail-fast, 401/403 carving, JSON-envelope parsing, distinct timeout/transport messages, and verify_ssl symmetry comment. Pre-PR the addon path was inline; the new system-service variant would have duplicated all of it. Helper takes the <path> between http://supervisor/ and /logs so addon-logs pass f"addons/{slug}" and system-service pass the bare service name.
• Fail-fast on empty SUPERVISOR_TOKEN (KP13 review item 1, KP13's option A): mirrors _restart_addon's pattern at settings_ui.py:780-789 for user-visible features. The is_running_in_addon() gate keys off truthy SUPERVISOR_TOKEN, so empty-token-at-call-time signals a detection/config mismatch — distinct error message ("absent at call time") so it doesn't read as "token rejected".
• verify=self.verify_ssl kept with symmetry comment (item 5, KP13's option B): refactor: pass verify_ssl to remaining direct-Supervisor httpx callers #1128's PR-body explicitly establishes the 3-site convention with the same "no-op on plain HTTP but bot-reviewers will keep flagging asymmetry" rationale. Drop here would have re-broken what refactor: pass verify_ssl to remaining direct-Supervisor httpx callers #1128 just unified.
• source="system_service" data-type-named, not route-named (PR-comment scope-add): matches KP13's own feat: consolidate ha_get_statistics into ha_get_history via source parameter #911 (source: Literal["history", "statistics"]) and feat: surface integration log levels in ha_get_logs/integration/addon (#956) #1003 (logger source) precedent for data-type-discriminating source enums. Slug namespace overlaps with source="supervisor" are acceptable because the source parameter disambiguates; docstring lists both slug semantics separately.
• Slug-enum runtime-validated against SYSTEM_SERVICE_SLUGS frozenset (caller layer, not Literal type): the same slug parameter has different semantics for source="supervisor" (free addon-slug string) vs source="system_service" (closed enum). Caller-layer validation gives the LLM the allowed-set in the error suggestion before the request fires; module-level frozenset is the project's empirically dominant pattern (vs nested Literal[...] per source).
• hassio_role: default → manager in both addon manifests with inline comment citing the live test result. Required for both /addons/<slug>/logs and /<service>/logs Supervisor REST paths.
• 17-item disposition: 16 adopted + 1 declined. Item 8 (level applies to source="supervisor") declined with rationale: warning is already emitted at tools_utility.py:139 — supervisor is in the level-not-applicable warn-tuple, pinned by test_level_param_emits_warning_for_supervisor_source. PR adds system_service to the same tuple plus a parity test. If the intent of item 8 was harder behavior (reject the call instead of warn), happy to revisit — but the existing pattern matches all other source/level pairs in the function.

Problems Encountered:

• Test response-shape parsing: first iteration of TestGetSystemServiceLogWrapper::test_403_role_hint_suggestion looked at body.get("suggestions", []) (top-level), but create_error_response nests them at body["error"]["suggestions"]. Fixed in 4463d7d; surfaced only because the test framework re-runs caught the AssertionError immediately. (One-pytest-iteration cost.)
• No conflict markers, no merge conflicts at HEAD. Branch hasn't been rebased onto current master since open; happy to rebase before merge if desired.

Suggested Improvements (post-merge):

• Live integration coverage for the Supervisor-direct paths is filed as out-of-scope here — the existing E2E suite uses a Supervisor-less testcontainer and adding a Supervisor sidecar is its own design discussion. A targeted test against a real HAOS instance (or a Supervisor-equipped Docker compose) would catch role/permission regressions at upstream Supervisor releases that current mocks won't.
• Common Supervisor-REST helper extraction: _fetch_addon_logs (tools_bug_report.py), _restart_addon (settings_ui.py), and the new _supervisor_logs_get all hit http://supervisor/... with Authorization: Bearer ${SUPERVISOR_TOKEN} and slightly different error handling. Extracting a shared module-level helper (covered as alternative in [FEATURE] Standardize verify_ssl on direct-Supervisor httpx callers #1127's body) would consolidate the four-site pattern. Out of scope here — fits as a follow-up to refactor: pass verify_ssl to remaining direct-Supervisor httpx callers #1128 once that lands.
• source="supervisor" semantic rename: the existing source value names a route ("via Supervisor proxy") while the new source="system_service" and the other four sources name data types. A rename to source="addon" would be semantically cleaner but is unrelated to [BUG] ha_get_logs(source="supervisor") returns 403 for every slug on add-on installs #1116 and would touch every caller; deferred per the project's enger-Scope policy.

Live-test plan (post-merge dev-channel deploy):

• ha_get_logs(source="supervisor", slug="core_mosquitto") — pre-fix returns 403 (verified in this session against stable v7.4.1); post-deploy expected 200 with logs.
• ha_get_logs(source="supervisor", slug="self") and slug="81f33d0f_ha_mcp" — same expectation.
• ha_get_logs(source="system_service", slug="supervisor") and the other six service slugs — expected 200.
• ha_get_logs(source="system_service", slug="invalid_service") — expected validation error before HTTP.
• ha_get_logs(source="supervisor", slug="nonexistent_addon") — expected 404 with the slug-not-installed suggestion.

[Patch76]

TL;DR for 4463d7d since the Implementation Summary above runs long:

• 16 of your 17 CR items adopted; item 8 declined with rationale — level warning is already emitted at tools_utility.py:139 (supervisor is in the warn-tuple, pinned by test_level_param_emits_warning_for_supervisor_source). If the intent was harder than warn (e.g. raise on level+slug), that's a different design call — flag it.
• Scope-add from your 12:42 comment landed: hassio_role: default → manager in both addon manifests + new source="system_service" for the seven /<service>/logs endpoints (slug-enum validated against {supervisor, host, core, dns, audio, multicast, observer}).
• Pre-fix bug live-reproduced against stable v7.4.1 (core_mosquitto, 81f33d0f_ha_mcp, self all return 403). Post-merge dev-channel deploy re-runs the five-call test matrix from the Implementation Summary.

Full 17-item disposition: PR body table.

[kingpanther13]

Round 2 looks clean — 16 of 17 items addressed, item 8 decline is valid (the level warning is emitted from the tuple at tools_utility.py:160-167, now extended to system_service). Role bump + system_service source verified live against my test instance.

In addition to the above, please address:

Critical

1. source="error_log" is also broken on Supervisor installs — same shape as #1116. HA Core's bootstrap.py (current dev) sets err_log_path = None when SUPERVISOR env is present, which means hass.data[DATA_LOGGING] is never set, and the APIErrorLog view registration is gated on if DATA_LOGGING in hass.data: — so /api/error_log is not registered at all on HA OS / Supervised, returning 404 by-design. Verified empirically and against home-assistant/core source. Fix shape parallels what you already built: when is_running_in_addon(), route error_log to _supervisor_logs_get("core") (HA Core's container log via Supervisor — same content, different transport). On non-addon installs keep the current /api/error_log path. Helper is already in place; this is a one-branch addition in client.get_error_log() plus a tool-layer note. Worth landing in this PR since it's the same root cause and same fix shape — closes the "log fetch doesn't work on Supervisor installs" class of bugs in one go.

While you're in there (nits, address inline)
2. slug param is silently ignored on non-supervisor/non-system_service sources. tools_utility.py:154-167 warns when entity_id/end_time are passed to non-logbook sources, and warns when level is passed to non-system/error_log sources. slug has no equivalent — passing slug="x" with source="logbook" is silently dropped. Add a third warning: if source not in ("supervisor", "system_service") and slug is not None:.
3. Role escalation is undocumented. hassio_role: default → manager is a meaningful permission bump (the addon can now start/stop/install/update other addons, read all their info, etc.). The addon-config comment is good for code reviewers but users updating the addon won't see it. One-line note in homeassistant-addon/DOCS.md (and the dev sibling per the dev-first translation rule) calling out the new role + why would close the doc gap.

[Patch76]

Round-2 → Round-3 follow-up — addressed in a49dbc3:

Critical 1 (error_log Supervisor branch) — HomeAssistantClient.get_error_log() now branches on is_running_in_addon() and routes to _supervisor_logs_get("core") for the addon path. HA Core's bootstrap.py:641-651 err_log_path = None behavior verified against current dev. TestGetErrorLogBranchSelection pins both branches.

Nit 2 (slug warning) — third warning branch in tools_utility.ha_get_logs for source not in ("supervisor", "system_service") and slug is not None. TestSlugParameterIncompatibilityWarning parametrizes over four non-supervisor sources and two supervisor sources.

Nit 3 (role docs) — ### Supervisor Permissions section in homeassistant-addon/DOCS.md (Security) + ### Permissions subsection in homeassistant-addon-dev/DOCS.md (Configuration), citing the role bump rationale and #1116.

Local: 1711 unit tests pass, ruff clean. PR description updated to reflect the extended scope.

[kingpanther13]

Round-3 verified: error_log routes via Supervisor on addon installs, slug warning fires for non-supervisor sources, role-bump documented. All 17+3 review items addressed, tests added, live-confirmed on Fork-Dev. LGTM.

[github-actions]

🧪 Your changes are now in the dev channel!

Your PR has been merged to master and is available for testing in the dev channel.

Test your changes before the next stable release (biweekly Wednesday):
📖 Dev Channel Documentation

Quick start

# Run dev version
uvx ha-mcp-dev

# Check version
uvx ha-mcp-dev --version

Docker:

docker pull ghcr.io/homeassistant-ai/ha-mcp:dev
docker run --rm -i \
  -e HOMEASSISTANT_URL=http://your-ha:8123 \
  -e HOMEASSISTANT_TOKEN=your_token \
  ghcr.io/homeassistant-ai/ha-mcp:dev

---

Found an issue? Please open a new bug report and mention this PR for context.