fix(installer): report unexpected Docker access

[chengjiew]

Summary

• report when Linux Docker is reachable for a non-root user outside the docker group
• include DOCKER_HOST and docker.sock diagnostics so QA can see why the non-docker negative test will not reproduce on that host
• keep the installer fast path non-blocking when Docker access already works

Fixes #3952

Test plan

• LC_ALL=C NPM_CONFIG_CACHE=/tmp/nemoclaw-npm-cache-3952 npm run build:cli
• LC_ALL=C NPM_CONFIG_CACHE=/tmp/nemoclaw-npm-cache-3952 npx vitest run test/install-preflight.test.ts
• git diff --check

Note: a first full test run without LC_ALL=C hit the local host's missing C.UTF-8 locale warning in one existing assertion; rerunning with LC_ALL=C passed 99/99.

Signed-off-by: Chengjie Wang chengjiew@nvidia.com

Summary by CodeRabbit

• New Features

  • Improved diagnostic reporting when Docker is reachable for a non-root user without standard group membership: logs now include current username, DOCKER_HOST status/value, and socket ownership/permission details.

• Tests

  • Added focused integration tests covering non-standard Docker access, membership-remediation behavior, and root/non-root branches.
  • Added test helpers to simulate isolated system PATHs and executable stubs; test runner config updated to include these integration tests.

• Chores

  • Adjusted test file size budget for expanded tests.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[github-actions]

This repository limits contributors to 10 open pull requests. Please close or merge existing PRs before opening new ones.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 4d52728b-c2b5-4f70-b589-697b4560138e

📥 Commits

Reviewing files that changed from the base of the PR and between e582720 and e79fc65.

📒 Files selected for processing (1)

• test/e2e-scenario/framework-tests/e2e-live-project-config.test.ts

---

📝 Walkthrough

Walkthrough

Adds report_unexpected_docker_access() to log username, DOCKER_HOST, and docker.sock ownership when Docker is reachable for a non-root user not in the docker group; invokes it from ensure_docker() after successful docker info. Adds test helpers and a sourced Docker-bootstrap Vitest suite, adjusts tests, CI budget, and vitest config.

Changes

Docker Access Diagnostics

Layer / File(s)	Summary
Docker diagnostics function and integration scripts/install.sh	Introduces report_unexpected_docker_access() which returns early for root or docker-group users, otherwise logs username, optional DOCKER_HOST, and /var/run/docker.sock mode/owner/group when stat is available; invoked from ensure_docker() after a successful docker info fast path.
Test helper: isolated PATH and executable writer test/helpers/installer-sourced-env.ts	Adds INSTALLER_PAYLOAD, buildIsolatedSystemPath() (creates a temp dir and symlinks /usr/bin and /bin entries excluding node/npm/npx), TEST_SYSTEM_PATH, and writeExecutable() to create stub executables for tests.
Installer Docker bootstrap (sourced) tests test/install-preflight-docker-bootstrap.test.ts	Adds a Vitest suite that sources the installer in a bash subprocess with a fake PATH (stubbed docker, id, stat, sudo, systemctl, uname) and validates: non-root unexpected daemon reachability diagnostics, newgrp prompts when membership isn't active, active-shell docker access behavior, and root behavior skipping group checks.
Preflight test file edits test/install-preflight.test.ts	Reorders imports and removes the inline installer Docker bootstrap (sourced) block (moved to the new dedicated test file).
CI test-size budget ci/test-file-size-budget.json	Reduces legacyMaxLines budget for test/install-preflight.test.ts from 4396 to 4207.
Vitest config vitest.config.ts	Includes test/install-preflight-docker-bootstrap.test.ts in the installer-integration conditional include list and removes it from the cli project's exclude list.
E2E config test/e2e-scenario/framework-tests/e2e-live-project-config.test.ts	Adds test/install-preflight-docker-bootstrap.test.ts to the INSTALLER_INTEGRATION_TESTS array for gated installer-integration E2E selection.

Sequence Diagram(s)

sequenceDiagram
  participant Installer
  participant ensure_docker
  participant DockerCLI
  participant report_unexpected_docker_access
  Installer->>ensure_docker: call ensure_docker()
  ensure_docker->>DockerCLI: run "docker info"
  DockerCLI-->>ensure_docker: success
  ensure_docker->>report_unexpected_docker_access: invoke to emit diagnostics
  report_unexpected_docker_access-->>Installer: print username, DOCKER_HOST, socket stat

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰
I sniffed the socket late at night,
A user found Docker working right,
I hopped and logged the host and perms,
So install tales avoid false terms,
Hooray — diagnostics shine a light!

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding diagnostic reporting for unexpected Docker access in the installer script.
Linked Issues check	✅ Passed	Code changes successfully implement all objectives from issue #3952: detecting unexpected Docker access [#3952], capturing diagnostics about DOCKER_HOST and socket ownership [#3952], and maintaining non-blocking installer behavior [#3952].
Out of Scope Changes check	✅ Passed	All changes are directly aligned with issue #3952 objectives: installer diagnostics, test infrastructure for validation, and configuration updates to support the new test suite.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/3952_docker-access-diagnostics

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

E2E Advisor Recommendation

Required E2E: installer-integration, cloud-e2e
Optional E2E: cloud-onboard-e2e, wsl-e2e, launchable-smoke-e2e

Dispatch hint: cloud-e2e

Workflow run

Full advisor summary

E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required E2E

• installer-integration (low): Must run because the PR changes scripts/install.sh and the installer-integration Vitest project membership; this is the targeted CI suite for sourced installer preflight/bootstrap behavior, including the newly added Docker bootstrap test file.
• cloud-e2e (high): Must run a real install → onboard → sandbox → inference path because installer Docker bootstrap changes can affect the end-user non-interactive install flow before sandbox creation.

Optional E2E

• cloud-onboard-e2e (high): Useful additional coverage for the public/curl installer path, sandbox health, and security checks after changing the installer payload, but largely overlaps the required full install/onboard validation.
• wsl-e2e (high): Optional because scripts/install.sh is in the WSL workflow path filter and WSL has special Docker-skip behavior; the changed Linux Docker bootstrap is mostly bypassed there, but this can catch accidental installer regressions on WSL.
• launchable-smoke-e2e (high): Optional confidence for community launchable/bootstrap install flow after installer preflight changes; run if extra install-path confidence is desired.

New E2E recommendations

• docker-bootstrap-and-host-security-posture (high): Existing E2E runners usually already have Docker reachable, so they do not exercise the clean Linux host path where Docker is missing, the user is not in the docker group, sudo installs Docker, usermod runs, and non-interactive sg/newgrp reactivation re-execs the installer. Current coverage for those branches is stubbed installer-integration rather than a real host bootstrap.
  • Suggested test: Add a clean Ubuntu VM installer E2E that starts from no Docker or an inactive docker group membership and verifies install.sh completes or exits with the intended relogin/newgrp guidance without weakening Docker daemon access checks.

Dispatch hint

• Workflow: .github/workflows/nightly-e2e.yaml
• jobs input: cloud-e2e

[github-actions]

E2E Scenario Advisor Recommendation

Required scenario E2E: None
Optional scenario E2E: None

Workflow run

Full scenario advisor summary

E2E Scenario Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required scenario E2E

• None. No Vitest live scenario run is recommended. The only changes under test/e2e-scenario are framework contract tests for gated Vitest project includes, and the vitest.config.ts diff adds an installer-integration test include/exclusion without changing the e2e-scenarios-live project, scenario registry, live runtime support, manifests, expected state, fixtures, phases, or the e2e-vitest-scenarios workflow. The installer script and installer integration tests are outside the layered typed scenario suite and do not map to a live-supported scenario ID.

Optional scenario E2E

• None.

Relevant changed files

• test/e2e-scenario/framework-tests/e2e-live-project-config.test.ts
• vitest.config.ts

[github-actions]

PR Review Advisor

Findings: 1 needs attention, 3 worth checking, 0 nice ideas
Since last review: 0 prior items resolved, 4 still apply, 0 new items found

Review findings

🛠️ Needs attention

• Issue-requested Docker identity and effective-id diagnostics are still incomplete (scripts/install.sh:2215): Issue [NemoClaw][All Platforms][Install] Non-docker user can run 'docker info' successfully despite docker.sock being root:docker 660 #3952 asks maintainers to distinguish Docker access causes for a non-root, non-docker user where `docker info` unexpectedly succeeds. The patch reports that Docker is reachable, whether DOCKER_HOST is set, and numeric socket owner/mode, but it still omits several requested or issue-relevant probes: Docker executable/wrapper identity, full `id`-style effective UID/groups, socket file type or symbolic `srw-rw----`, Docker version/client-server context, and daemon owner/service context. That leaves the linked issue's wrapper, environment, identity, socket-shape, and daemon-owner hypotheses only partially diagnosable from installer output.
  • Recommendation: Add sanitized diagnostics for Docker command identity/path, effective UID/groups, socket file type plus owner/mode, and daemon owner/service context; or explicitly document which linked-issue probes are intentionally out of installer scope and where QA should collect them. Cover the chosen contract with sourced tests for wrapper/path, effective-group drift, socket file type, and daemon-owner scenarios.
  • Evidence: The linked issue lists `which docker`, `type docker`, `echo "$DOCKER_HOST"`, and `id` under "Quick diagnostics to attach" and asks to confirm `/var/run/docker.sock` as `root:docker` with `srw-rw----` plus compare that the daemon is running as root. The diff adds `info "DOCKER_HOST is set to: $DOCKER_HOST"` and `stat -Lc '%a %U %G %n' /var/run/docker.sock`, and the new test asserts `660 root docker /var/run/docker.sock`; no code/test evidence emits `which`/`type`/`command -v`, full `id`, socket file type or symbolic permissions, Docker version, or daemon-owner details.

🔎 Worth checking

• Source-of-truth review needed: scripts/install.sh::report_unexpected_docker_access: The advisor marked localized patch analysis as needs_followup.
  • Recommendation: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
  • Evidence: The helper runs after the `docker info` fast path, logs possible causes, and returns successfully. It does not document a complete source-fix constraint or removal condition.
• Redact DOCKER_HOST before writing installer diagnostics (scripts/install.sh:2218): The new diagnostic prints environment-controlled `DOCKER_HOST` verbatim. Docker host URLs can contain embedded usernames, passwords, tokens, private hostnames, query strings, fragments, or control characters. Installer logs are likely to be shared with QA or support, so this can disclose credentials/internal routing details or forge confusing multiline log output.
  • Recommendation: Log only a sanitized representation, such as set/unset plus redacted scheme/authority. Strip userinfo, query strings, fragments, and control characters before printing. Add a regression test using a credential-bearing DOCKER_HOST value with control characters and assert sensitive parts are omitted while the diagnostic remains non-fatal.
  • Evidence: `report_unexpected_docker_access()` contains `info "DOCKER_HOST is set to: $DOCKER_HOST"`. The added sourced test does not set `DOCKER_HOST`, so the sensitive branch and redaction behavior are untested.
• Document the source boundary and removal condition for the localized Docker-access diagnostic (scripts/install.sh:2196): `report_unexpected_docker_access()` is a localized diagnostic for an invalid host state: Docker is reachable by a non-root user outside the docker group. The comments identify the state and list possible external causes, but the code does not fully record why the source cannot be fixed in this PR, what complete regression coverage proves the assumptions, or when this diagnostic can be removed.
  • Recommendation: Document the source boundary near the helper or in linked issue notes: which parts are external host configuration, why NemoClaw can only diagnose rather than repair them here, what tests cover the diagnostic contract, and what condition would allow removing the helper. Prefer a source fix if a NemoClaw-controlled source is identified.
  • Evidence: The helper runs after `docker info` succeeds, prints possible causes such as wrapper/socket ACL/policy configuration, and continues. The test covers one stubbed non-root/non-docker success path, but no removal condition or full source-fix rationale is present.

🌱 Nice ideas

• None.

Consider writing more tests for

• **Runtime validation** — Add a sourced test where `DOCKER_HOST` is `tcp://user:token@example.internal:2376?x=secret#frag` plus newline/control characters, and assert diagnostics redact userinfo, token, query, fragment, and control characters while remaining non-fatal.. The changed production behavior is installer/bootstrap shell that reasons about real host identity, Docker CLI configuration, daemon/socket state, and group membership. Sourced tests cover the central branch and previous remediation paths, but runtime behavior depends on host-specific Docker access mechanisms and sensitive environment values.
• **Runtime validation** — Add a sourced test with a wrapper or alternate `docker` executable earlier on PATH and assert diagnostics report sanitized Docker command identity/path.. The changed production behavior is installer/bootstrap shell that reasons about real host identity, Docker CLI configuration, daemon/socket state, and group membership. Sourced tests cover the central branch and previous remediation paths, but runtime behavior depends on host-specific Docker access mechanisms and sensitive environment values.
• **Runtime validation** — Add a sourced test with different persisted versus effective group outputs and assert diagnostics emit an `id`-style effective UID/groups line.. The changed production behavior is installer/bootstrap shell that reasons about real host identity, Docker CLI configuration, daemon/socket state, and group membership. Sourced tests cover the central branch and previous remediation paths, but runtime behavior depends on host-specific Docker access mechanisms and sensitive environment values.
• **Runtime validation** — Add a sourced test where socket metadata includes file type/symbolic mode, proving output includes `srw-rw---- root docker /var/run/docker.sock` or an equivalent representation.. The changed production behavior is installer/bootstrap shell that reasons about real host identity, Docker CLI configuration, daemon/socket state, and group membership. Sourced tests cover the central branch and previous remediation paths, but runtime behavior depends on host-specific Docker access mechanisms and sensitive environment values.
• **Runtime validation** — Add a sourced test or documented runtime validation for daemon owner/service context, asserting a root-owned daemon/service is reported or that daemon-owner probing is intentionally skipped with rationale.. The changed production behavior is installer/bootstrap shell that reasons about real host identity, Docker CLI configuration, daemon/socket state, and group membership. Sourced tests cover the central branch and previous remediation paths, but runtime behavior depends on host-specific Docker access mechanisms and sensitive environment values.
• **Acceptance clause:** On this host, Docker's Unix socket is owned by `root:docker` with `660` permissions and the current user is NOT in the `docker` group. — add test evidence or identify existing coverage. `report_unexpected_docker_access()` checks non-root via `id -u`, checks persisted/effective groups via `id -nG`, and logs `stat -Lc '%a %U %G %n' /var/run/docker.sock`. The new test stubs `alice sudo` and asserts `660 root docker /var/run/docker.sock`. It does not emit the full group list or socket file type.
• **Acceptance clause:** Preconditions: `docker --version` # Docker version 29.4.3, build ... — add test evidence or identify existing coverage. No production diagnostic or test evidence reports Docker CLI/server version.
• **Acceptance clause:** Preconditions: `ls -l /var/run/docker.sock` # `srw-rw---- 1 root docker 0 May 11 11:41 /var/run/docker.sock` — add test evidence or identify existing coverage. Production logs numeric mode/owner/group/path as `660 root docker /var/run/docker.sock`; tests assert that numeric form. The output does not include socket type `s` or symbolic permissions `srw-rw----`.

Since last review details

Current findings:

• Source-of-truth review needed: scripts/install.sh::report_unexpected_docker_access: The advisor marked localized patch analysis as needs_followup.
  • Recommendation: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
  • Evidence: The helper runs after the `docker info` fast path, logs possible causes, and returns successfully. It does not document a complete source-fix constraint or removal condition.
• Issue-requested Docker identity and effective-id diagnostics are still incomplete (scripts/install.sh:2215): Issue [NemoClaw][All Platforms][Install] Non-docker user can run 'docker info' successfully despite docker.sock being root:docker 660 #3952 asks maintainers to distinguish Docker access causes for a non-root, non-docker user where `docker info` unexpectedly succeeds. The patch reports that Docker is reachable, whether DOCKER_HOST is set, and numeric socket owner/mode, but it still omits several requested or issue-relevant probes: Docker executable/wrapper identity, full `id`-style effective UID/groups, socket file type or symbolic `srw-rw----`, Docker version/client-server context, and daemon owner/service context. That leaves the linked issue's wrapper, environment, identity, socket-shape, and daemon-owner hypotheses only partially diagnosable from installer output.
  • Recommendation: Add sanitized diagnostics for Docker command identity/path, effective UID/groups, socket file type plus owner/mode, and daemon owner/service context; or explicitly document which linked-issue probes are intentionally out of installer scope and where QA should collect them. Cover the chosen contract with sourced tests for wrapper/path, effective-group drift, socket file type, and daemon-owner scenarios.
  • Evidence: The linked issue lists `which docker`, `type docker`, `echo "$DOCKER_HOST"`, and `id` under "Quick diagnostics to attach" and asks to confirm `/var/run/docker.sock` as `root:docker` with `srw-rw----` plus compare that the daemon is running as root. The diff adds `info "DOCKER_HOST is set to: $DOCKER_HOST"` and `stat -Lc '%a %U %G %n' /var/run/docker.sock`, and the new test asserts `660 root docker /var/run/docker.sock`; no code/test evidence emits `which`/`type`/`command -v`, full `id`, socket file type or symbolic permissions, Docker version, or daemon-owner details.
• Redact DOCKER_HOST before writing installer diagnostics (scripts/install.sh:2218): The new diagnostic prints environment-controlled `DOCKER_HOST` verbatim. Docker host URLs can contain embedded usernames, passwords, tokens, private hostnames, query strings, fragments, or control characters. Installer logs are likely to be shared with QA or support, so this can disclose credentials/internal routing details or forge confusing multiline log output.
  • Recommendation: Log only a sanitized representation, such as set/unset plus redacted scheme/authority. Strip userinfo, query strings, fragments, and control characters before printing. Add a regression test using a credential-bearing DOCKER_HOST value with control characters and assert sensitive parts are omitted while the diagnostic remains non-fatal.
  • Evidence: `report_unexpected_docker_access()` contains `info "DOCKER_HOST is set to: $DOCKER_HOST"`. The added sourced test does not set `DOCKER_HOST`, so the sensitive branch and redaction behavior are untested.
• Document the source boundary and removal condition for the localized Docker-access diagnostic (scripts/install.sh:2196): `report_unexpected_docker_access()` is a localized diagnostic for an invalid host state: Docker is reachable by a non-root user outside the docker group. The comments identify the state and list possible external causes, but the code does not fully record why the source cannot be fixed in this PR, what complete regression coverage proves the assumptions, or when this diagnostic can be removed.
  • Recommendation: Document the source boundary near the helper or in linked issue notes: which parts are external host configuration, why NemoClaw can only diagnose rather than repair them here, what tests cover the diagnostic contract, and what condition would allow removing the helper. Prefer a source fix if a NemoClaw-controlled source is identified.
  • Evidence: The helper runs after `docker info` succeeds, prints possible causes such as wrapper/socket ACL/policy configuration, and continues. The test covers one stubbed non-root/non-docker success path, but no removal condition or full source-fix rationale is present.

Workflow run details

This is an automated advisory review. A human maintainer must make the final merge decision.

[wscurran]

✨
Related open issues:

• #3952 [NemoClaw][All Platforms][Install] Non-docker user can run 'docker info' successfully despite docker.sock being root:docker 660

[prekshivyas]

LGTM. Correctly addresses #3952. The host grants Docker access via a non-group path (socket ACL / DOCKER_HOST / wrapper), which can't be 'fixed' in the installer — so surfacing it is the right call. report_unexpected_docker_access() is info-only (no change to install flow), correctly short-circuits for root and docker-group members, and only logs the anomaly (with DOCKER_HOST + socket stat) when docker is reachable yet the user isn't in the group — explaining why the 'non-docker user denied' negative test won't reproduce on such hosts. CI green; test harness extended for the new stat path.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@test/install-preflight.test.ts`:
- Around line 3169-3200: The test file exceeds the size budget because you added
a new Docker diagnostics test; extract the "reports when Docker is reachable for
a non-docker-group Linux user" test and any closely related helpers into a new
test file (e.g., create a new spec file) to reduce
test/install-preflight.test.ts back under the limit. Move the test block and the
supporting stub utilities used here (references: the it(...) test title,
runEnsureDockerWithStubs, dockerScript/idScript/statScript literals, and
assertions that reference sudoLog and result) into the new file, update
imports/exports so runEnsureDockerWithStubs is imported from the shared helper
module (or split helper into a shared helpers file if needed), and ensure test
suite setup/teardown and any path-relative requires are adjusted so the moved
test runs unchanged.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: e1049a82-4044-4330-ba45-af7eaf4b2fa3

📥 Commits

Reviewing files that changed from the base of the PR and between 8827570 and 089bedb.

📒 Files selected for processing (2)

• scripts/install.sh
• test/install-preflight.test.ts

[prekshivyas]

@chengjiew the only remaining red check is codebase-growth-guardrails, and this one needs an author change.

What's happening: this PR adds ~38 lines to test/install-preflight.test.ts (the new it("reports when Docker is reachable for a non-docker-group Linux user") test + the statScript helper param). That file is a pinned legacy file (budget 4396), and the guardrail only lets legacy budgets ratchet down, never up — so bumping the budget can't pass (I tried that; reverted it in c53f9929).

Fix: move the new test out of the pinned file so it doesn't grow:

• Extract runEnsureDockerWithStubs (+ its deps writeExecutable / TEST_SYSTEM_PATH / INSTALLER_PAYLOAD) into a shared helper, e.g. test/helpers/installer-docker-bootstrap.ts, and import it back into install-preflight.test.ts.
• Put the new test in its own file (e.g. test/install-preflight-docker-reachable.test.ts) importing that helper.
• Lower the test/install-preflight.test.ts budget entry to the file's new (smaller) line count.

Everything else (formatting, etc.) is green. Once the new test lives in its own file and the legacy file shrinks, this'll pass.

[prekshivyas]

Update: I went ahead and pushed the fix myself (e5827206) so this isn't blocked on you.

What I did (the guardrail-compliant relocation I described above):

• Moved the entire installer Docker bootstrap (sourced) describe block out of test/install-preflight.test.ts into a new test/install-preflight-docker-bootstrap.test.ts (this is where your new non-docker-group test now lives, alongside the 3 sibling tests).
• Extracted the shared sourced-env helpers (INSTALLER_PAYLOAD / TEST_SYSTEM_PATH / writeExecutable / buildIsolatedSystemPath) into test/helpers/installer-sourced-env.ts, imported by both files — no duplication.
• Wired the new file into the gated installer-integration vitest project (not cli), so it runs in exactly the same place the originals did (NEMOCLAW_RUN_INSTALLER_TESTS=1), not in every cli shard.
• install-preflight.test.ts drops 4396 → 4207 lines; lowered its budget entry to match.

Verified locally: installer-integration project is green (122 tests, incl. your new one) and biome/format is clean. The codebase-growth-guardrails check should pass now. Thanks for the fix — nice catch on the Docker-reachable-without-group-membership path.