[seancdavis]

Some of the CLI's tests were quietly calling Netlify's real extensions service when they should only talk to the fake API server they run against. A recent change started sending the tests' fake login token with that call. The real service rejects that token, and the CLI then carried on without any site information, which broke a test that checks the account ID. This sends that call to the fake server during tests and turns the check back on. Nothing changes for people using the CLI.

What changed

• BaseCommand.getConfig now passes testOpts to resolveConfig when NETLIFY_API_URL points at a loopback host (localhost, 127.0.0.1, [::1]). This goes through a new getLocalApiTestOpts helper in src/utils/local-api-test-opts.ts. In @netlify/config, testOpts.host only decides where the extensions request goes; the API client already gets the same host. netlify build (src/lib/build.ts) already passes testOpts for any NETLIFY_API_URL. This path is limited to loopback hosts because @netlify/config sends the request, token included, over plain http:// to any host that isn't a Netlify one.
• The mock extensions routes in tests/integration/utils/mock-api.ts now match any site or account ID; before, they matched only the literal site_id / account_id. The same routes are added to tests/integration/utils/mock-api-vitest.ts, which had none.
• The account.id assertion in tests/integration/commands/dev/v2-api.test.ts, commented out in feat: deploy server config #8639, is back.

Background: netlify/build#7268 removed the send_build_bot_token_to_jigsaw flag, so @netlify/config 25.3.0 always sends the token. The real team endpoint returns 403 for fake-token, and getConfig then quietly re-resolves offline. Real users are unaffected: real sites already return send_build_bot_token_to_jigsaw: true to the CLI.

How it was verified

• typecheck, lint, format:check and test:unit all pass (756 tests).
• v2-api.test.ts passes, 24 of 24. With the old base-command.ts, "receives context" fails with the same account.id error CI showed.
• dev.test.ts, build-program.test.ts, build.test.ts and telemetry.test.ts pass.
• Draft because: the Codex review passes (simplicity, security, spec) haven't run. Every attempt was rate-limited with a 429. The full CI suite is the other remaining check.

Closes EX-3522

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 9f3dd846-79fb-4e3e-ae9b-adeafc63080a

📥 Commits

Reviewing files that changed from the base of the PR and between ee98cc7 and dcb7c49.

📒 Files selected for processing: 6

• src/commands/base-command.ts
• src/utils/local-api-test-opts.ts
• tests/integration/commands/dev/v2-api.test.ts
• tests/integration/utils/mock-api-vitest.ts
• tests/integration/utils/mock-api.ts
• tests/unit/utils/local-api-test-opts.test.ts

🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

• netlify/blueprints (manual)

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 3 remain after this review.

📝 Summary

Summary by CodeRabbit

• New Features

  • Local API testing now supports loopback hosts, including localhost, 127.0.0.1, and [::1].
  • Host and scheme settings are preserved when connecting to supported local endpoints.
  • Non-local or invalid hosts are safely excluded from local API test configuration.

• Bug Fixes

  • Improved integration test coverage and mock API handling for dynamic site and account identifiers.
  • Restored validation that the expected account ID is returned.

Configuration loading now passes local API test options for recognized loopback hosts. Unit tests cover the host checks. Integration test mocks accept dynamic route identifiers and provide two successful empty-array responses. The context integration test now asserts the expected account ID.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix

Suggested reviewers: serhalp

Merge Risk: 🔵 Low · up to dcb7c

The change is mergeable with owner awareness: HTTPS loopback configurations may fail while retrieving extensions. The supplied HTTP integration setup is unaffected.

Security architecture risk: 🔵 Low · up to dcb7c

The change is narrowly scoped to recognized loopback hosts and test mocks. No new remote authority or privilege expansion was established. Some uncertainty remains because the inspected dependency differs from the locked version, and HTTPS loopback configurations may receive inconsistent transport handling.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The new routing applies to a CLI invocation configured with a recognized local API host, rather than introducing an arbitrary remote extensions override. The integration helpers supply an HTTP localhost URL and a fake token.

Trust Boundaries and Controls

• observed — NETLIFY_API_URL already determines the host and scheme used to construct the ordinary API client with the user's token. The new helper separately checks the parsed hostname against a loopback allowlist before supplying extensions test options; malformed and nonmatching hosts return undefined.

Pre-merge checks: 5

Check name	Status	Explanation
Title check		The title clearly summarizes the main change: mocking the extensions API in integration tests.
Description check		The description directly explains the test isolation issue, the loopback routing fix, the mock route updates, and the restored assertion.
Docstring Coverage		No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 6…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 6 files.

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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

[github-actions]

📊 Benchmark results

Comparing with ee98cc7

• Dependency count: 1,022 (no change)
• Package size: 381 MB ⬆️ 0.00% increase vs. ee98cc7
• Number of ts-expect-error directives: 280 (no change)

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/netlify-cli@8640

commit: dcb7c49