[boristane]

The Cloudflare token link that the CLI opens now keeps edit on Notifications and Workers Observability. Every other permission stays read. With the old link, Polylane could not create alert subscriptions, so no account connected from the CLI got Workers issues or alerts.

Why: In prod, 15 Cloudflare accounts connected from the CLI (origin: cli) have the alerts flag set and no webhook destination. Creating a webhook destination or a notification policy needs Notifications Write. The Workers Issues automation and alerts need Workers Observability Write. This copy of the token link changed both to read. Nominal makes the same change in coreplanelabs/nominal#6405.

Where to look

1. Read-only transform keeps edit for the two alert subscription keys. ⚠ It must stay the same as nominal's packages/util/cloudflare-token-url.ts.
2. Manual steps tell a person who creates the token by hand to add the two edit grants.
3. Test checks that only these two keys keep edit.

Feedback wanted: Is the wizard note clear about what Polylane can change in the account?

Risk: A new CLI token can create and delete notifications and Workers observability alerts in the customer's account. Tokens that already exist do not change. Roll back with a revert.

Verified: npm test passes (622). npm run lint passes. npm run typecheck has 2 errors in src/commands/integration/connect.ts from the generated client's IntegrationType; this change does not touch that file.

Decisions (1)

• Two edit grants, not a full token. The account stays readOnly: true in Polylane, and agent tool writes stay blocked. Only the alert setup that Polylane runs on connect needs these two groups.

Validation (3 criteria)

Criterion	Proof
Read-only link keeps edit only on notifications and workers_observability	test/cloudflare-token-url.test.ts
No other CLI behavior changes	npm test: 622 pass, 0 fail
A CLI connect creates the destination and the Workers issues policy	Human-gated: needs nominal#6405 deployed and a live Cloudflare account

🤖 Generated with Claude Code

[polylane]

Warning

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

This change only edits the permission list in the Cloudflare token URL the CLI builds, so no deployed resource runs the new code and existing account tokens stay as they are. The affected accounts stayed steady over 72h: coreplane-prod served 299k–800k Worker requests per hour at 34–52 errors per hour (mean 419k requests, 41 errors).

Check	Result
Impact assessment	Production impact not verified
Security review	Passed · 6 ruled out

View the full analysis →

Also considered · 3 refuted

• Refuted · Keeping edit on notifications and workers_observability lets Polylane write customer account config · No attacker input and no write: the customer creates the token in their own Cloudflare dashboard after the note at connect.ts:580-585 names the two groups, connect.ts:856 still marks the account readOnly: true, and no code path in this diff performs any write.
• Refuted · The new edit branch could drop or duplicate a permission for a de-duplicated key · Both alert keys have a single edit entry (cloudflare-token-url.ts:140, :193), so the first-wins de-duplication cannot shadow them; run/send/purge entries are dropped at :228 before the key is added, which is the existing behaviour.
• Refuted · The CLI copy diverges from the nominal copy that the alert routing depends on · Each copy only builds a browser URL from its own constant list.

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 55cddf4 for production impact and security. You can ask follow-ups by mentioning @polylane in a comment.}

[boristane]

LGTM: The token transform preserves edit only for the two intended alert-subscription groups, and the wizard accurately names those exceptions.

Reviewed the full diff, traced the affected callers, compared the two-grant exception with nominal#6405, and made a second pass over the permission transform and interactive/headless token paths. No blocking findings. The connect request still sends readOnly: true; existing tokens are unaffected. The updated test checks both required edit grants and rejects other non-read grants in the default read-only URL.

Local verification on Node v22.23.4:

• npm ci: passed.
• npm run codegen: passed against the live API spec.
• npm run typecheck: reproduced the two reported IntegrationType/conductor errors at src/commands/integration/connect.ts:422 and :1497. That file is unchanged from the PR base; these are unrelated to this diff.
• npm run lint: passed.
• npm run test: 622 passed, 0 failed.
• git diff --check: passed.

The production count of 15 affected accounts is not independently verifiable from this code review. End-to-end destination/policy creation remains unverified and depends on the companion backend deployment and a live Cloudflare account, as the PR notes.

[github-actions]

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