[nwm-54]

polylane integration connect --type circleci --api-key <token> now connects a CircleCI organization. When the personal token reaches more than one organization, the CLI shows a picker in a terminal. In non-interactive mode it names --organization-id and lists the organizations.

Why: The Polylane API and console can connect CircleCI, but the CLI could not. Agents and the install script use the CLI to connect integrations.

Where to look

1. Organization picker: reads the reachable organizations from the API error, then retries with the chosen one. This is the same shape as the Neon connect.
2. Wizard step: one secret step for the token, plus an optional --organization-id.
3. Picker entry: CircleCI joins Depot under --category ci-cd.
4. Tests: a single-org connect, the non-interactive hint, and the rethrow when an organization was already chosen or none are listed.

Feedback wanted: Is --organization-id the right flag name, or should it match the console's wording, "organization"?

Risk: Adds one connect type. CircleCI connections are still behind the circleci_enabled flag on the server. A workspace without it gets the API's "not available" message. Roll back by reverting.

Verified: tsc --noEmit, eslint and all 619 tests pass. The client was generated from the production spec, which already has the CircleCI connect body. A live connect against UAT is still human-gated: no CircleCI token was available.

🤖 Generated with Claude Code

[polylane]

Warning

Polylane could not verify the production impact of this pull request.

I read the rebased connect.ts and its callers: the CircleCI branch is additive, keyed only on body.type, and no other connect path uses the new flag. The attached cloud accounts do not execute this CLI code, so their traffic and error baselines are unaffected.

View the full analysis →

Also considered · 3 refuted

• Refuted · New --organization-id flag or CircleCI branch breaks connect dispatch for other integration types · The added branch is keyed on a new body.type value and the shared command flags are purely additive; the option-count test is updated in the same change, and the rebased base commit does not touch connect.ts.
• Refuted · The multi-organization picker retries the connect call and amplifies load · One bounded retry per explicit user connect, guarded against the already-chosen case; there is no loop and no server-side fanout to load-amplify.
• Refuted · The CircleCI path needs a runtime prerequisite that nothing provisions · The only runtime input is the user's own API token; nothing in the change reads an unprovisioned env var, secret, queue, bucket, or binding.

Analysed against 8 cloud accounts and 1 repository

• Cloud accounts: coreplane-prod, baseberry-uat, coreplane-infra, coreplane, coreplane-gtm, 251714435813, Polylane, nominal-493716
• Repository: coreplanelabs/cli

Polylane could not find the cloud resources this repository manages, so this review looked at the entire cloud account. Connect this repository to its resources and the next review will focus on exactly what this code deploys to.

_{Polylane analysed 5262ed1 for production impact. You can ask follow-ups by mentioning @polylane in a comment.}

Did this help? React 👍 or 👎 so the next review is sharper.

Previous verdicts (1)

Head	Verdict	Analysis
37b6b01	Production impact not verified	analysis

[nwm-54]

Level	Count
P0	0
P1	0
P2	0
contested	0

debate-review on 37b6b01, main claude, second codex.

LGTM: the CircleCI connect copies the existing Neon multi-organization flow and I found no correctness, security or standards defects. Reviewed connectCircleci and circleciOrganizations (src/commands/integration/connect.ts:772-812), the wizard step (1386-1408), how it is dispatched in connectWithCredentials (1479-1480), the new --organization-id option and example, and the ci-cd picker entry. Compared line by line with connectNeon (src/commands/cloud/connect.ts:447-486). The guards match: it rethrows on a non-API error, a non-400 status, an organizationId already sent, or empty organization metadata. The non-interactive path raises a USAGE CLIError with a hint, as AGENTS.md requires ("Throw CLIError ... Always pass an ExitCode and, when useful, a hint string"). An empty or whitespace --organization-id becomes undefined, so the picker still runs. The PR body's claims hold against the code. The tests cover the single-org pass-through, the non-interactive hint, and both rethrows. The interactive picker branch is not tested, and neither is Neon's. No docs or SKILL.md list the integration types, so there is no docs drift. Spec axis skipped: no spec source. One cosmetic note, below the bar: if the API returns an organization without a slug, the hint prints name (). On the flag-name question, --organization-id matches the body field organizationId, and other flags in this command follow the same pattern (--account-id). Limitation: this session only had read-only file tools. I did not run npm ci, codegen, typecheck, lint or test as REVIEW.md step 4 requires. That gap is in this review, not in the PR.

[nwm-54]

LGTM: The current-head debate review found no defects. Code generation, typecheck, lint, and all 619 local tests passed. CI passed on Node 20, 22, and 24. No review threads remain open.

[nwm-54]

LGTM

[nwm-54]

LGTM

[github-actions]

Auto-approved: nwm-54 reviewed this PR and posted an LGTM verdict (see its review). A repo admin enabled this via the auto-approve workflow.