Skip to content

fix(sdk): reject Cloudflare-native model IDs, bridge multi-part auth env vars#397

Open
sentry-junior[bot] wants to merge 5 commits into
mainfrom
fix/cloudflare-pi-selector-config
Open

fix(sdk): reject Cloudflare-native model IDs, bridge multi-part auth env vars#397
sentry-junior[bot] wants to merge 5 commits into
mainfrom
fix/cloudflare-pi-selector-config

fix(sdk): reject Cloudflare-native model IDs, bridge multi-part auth …

c7f30c8
Select commit
Loading
Failed to load commit list.
@sentry/warden / warden: code-review completed Jun 5, 2026 in 7m 20s

1 issue

code-review: Found 1 issue (1 medium)

Medium

`findMissingCloudflareEnv` only checks the first set model field, skipping the Cloudflare env check when a non-Cloudflare `model` is paired with a Cloudflare `auxiliaryModel`/`synthesisModel` - `packages/warden/src/action/workflow/schedule.ts:182-184`

findMissingCloudflareEnv resolves a single model via target.model ?? target.auxiliaryModel ?? target.synthesisModel, so when model is a non-Cloudflare selector (e.g. anthropic/claude-...) and auxiliaryModel/synthesisModel is cloudflare-workers-ai/..., the provider guard sees only the primary model and skips validation. CLOUDFLARE_ACCOUNT_ID is never checked at startup and the user still hits the opaque runtime failure this PR aims to prevent.

Also found at:

  • packages/warden/src/cli/main.ts:10
  • packages/warden/src/sdk/runtimes/model-selectors.ts:129
  • packages/warden/src/action/triggers/executor.ts:138-140
  • packages/warden/src/action/workflow/schedule.ts:18
  • packages/warden/src/cli/main.ts:1531
  • packages/warden/src/sdk/runtimes/model-selectors.test.ts:124

⏱ 5m 34s · 1.6M in / 79.4k out · $3.24

Annotations

Check warning on line 184 in packages/warden/src/action/workflow/schedule.ts

See this annotation in the file changed.

@sentry-warden sentry-warden / warden: code-review

`findMissingCloudflareEnv` only checks the first set model field, skipping the Cloudflare env check when a non-Cloudflare `model` is paired with a Cloudflare `auxiliaryModel`/`synthesisModel` 

`findMissingCloudflareEnv` resolves a single model via `target.model ?? target.auxiliaryModel ?? target.synthesisModel`, so when `model` is a non-Cloudflare selector (e.g. `anthropic/claude-...`) and `auxiliaryModel`/`synthesisModel` is `cloudflare-workers-ai/...`, the provider guard sees only the primary model and skips validation. `CLOUDFLARE_ACCOUNT_ID` is never checked at startup and the user still hits the opaque runtime failure this PR aims to prevent.

Check warning on line 10 in packages/warden/src/cli/main.ts

See this annotation in the file changed.

@sentry-warden sentry-warden / warden: code-review

[5R5-6HJ] `findMissingCloudflareEnv` only checks the first set model field, skipping the Cloudflare env check when a non-Cloudflare `model` is paired with a Cloudflare `auxiliaryModel`/`synthesisModel` (additional location) 

`findMissingCloudflareEnv` resolves a single model via `target.model ?? target.auxiliaryModel ?? target.synthesisModel`, so when `model` is a non-Cloudflare selector (e.g. `anthropic/claude-...`) and `auxiliaryModel`/`synthesisModel` is `cloudflare-workers-ai/...`, the provider guard sees only the primary model and skips validation. `CLOUDFLARE_ACCOUNT_ID` is never checked at startup and the user still hits the opaque runtime failure this PR aims to prevent.

Check warning on line 129 in packages/warden/src/sdk/runtimes/model-selectors.ts

See this annotation in the file changed.

@sentry-warden sentry-warden / warden: code-review

[5R5-6HJ] `findMissingCloudflareEnv` only checks the first set model field, skipping the Cloudflare env check when a non-Cloudflare `model` is paired with a Cloudflare `auxiliaryModel`/`synthesisModel` (additional location) 

`findMissingCloudflareEnv` resolves a single model via `target.model ?? target.auxiliaryModel ?? target.synthesisModel`, so when `model` is a non-Cloudflare selector (e.g. `anthropic/claude-...`) and `auxiliaryModel`/`synthesisModel` is `cloudflare-workers-ai/...`, the provider guard sees only the primary model and skips validation. `CLOUDFLARE_ACCOUNT_ID` is never checked at startup and the user still hits the opaque runtime failure this PR aims to prevent.

Check warning on line 140 in packages/warden/src/action/triggers/executor.ts

See this annotation in the file changed.

@sentry-warden sentry-warden / warden: code-review

[5R5-6HJ] `findMissingCloudflareEnv` only checks the first set model field, skipping the Cloudflare env check when a non-Cloudflare `model` is paired with a Cloudflare `auxiliaryModel`/`synthesisModel` (additional location) 

`findMissingCloudflareEnv` resolves a single model via `target.model ?? target.auxiliaryModel ?? target.synthesisModel`, so when `model` is a non-Cloudflare selector (e.g. `anthropic/claude-...`) and `auxiliaryModel`/`synthesisModel` is `cloudflare-workers-ai/...`, the provider guard sees only the primary model and skips validation. `CLOUDFLARE_ACCOUNT_ID` is never checked at startup and the user still hits the opaque runtime failure this PR aims to prevent.

Check warning on line 18 in packages/warden/src/action/workflow/schedule.ts

See this annotation in the file changed.

@sentry-warden sentry-warden / warden: code-review

[5R5-6HJ] `findMissingCloudflareEnv` only checks the first set model field, skipping the Cloudflare env check when a non-Cloudflare `model` is paired with a Cloudflare `auxiliaryModel`/`synthesisModel` (additional location) 

`findMissingCloudflareEnv` resolves a single model via `target.model ?? target.auxiliaryModel ?? target.synthesisModel`, so when `model` is a non-Cloudflare selector (e.g. `anthropic/claude-...`) and `auxiliaryModel`/`synthesisModel` is `cloudflare-workers-ai/...`, the provider guard sees only the primary model and skips validation. `CLOUDFLARE_ACCOUNT_ID` is never checked at startup and the user still hits the opaque runtime failure this PR aims to prevent.

Check warning on line 1531 in packages/warden/src/cli/main.ts

See this annotation in the file changed.

@sentry-warden sentry-warden / warden: code-review

[5R5-6HJ] `findMissingCloudflareEnv` only checks the first set model field, skipping the Cloudflare env check when a non-Cloudflare `model` is paired with a Cloudflare `auxiliaryModel`/`synthesisModel` (additional location) 

`findMissingCloudflareEnv` resolves a single model via `target.model ?? target.auxiliaryModel ?? target.synthesisModel`, so when `model` is a non-Cloudflare selector (e.g. `anthropic/claude-...`) and `auxiliaryModel`/`synthesisModel` is `cloudflare-workers-ai/...`, the provider guard sees only the primary model and skips validation. `CLOUDFLARE_ACCOUNT_ID` is never checked at startup and the user still hits the opaque runtime failure this PR aims to prevent.

Check warning on line 124 in packages/warden/src/sdk/runtimes/model-selectors.test.ts

See this annotation in the file changed.

@sentry-warden sentry-warden / warden: code-review

[5R5-6HJ] `findMissingCloudflareEnv` only checks the first set model field, skipping the Cloudflare env check when a non-Cloudflare `model` is paired with a Cloudflare `auxiliaryModel`/`synthesisModel` (additional location) 

`findMissingCloudflareEnv` resolves a single model via `target.model ?? target.auxiliaryModel ?? target.synthesisModel`, so when `model` is a non-Cloudflare selector (e.g. `anthropic/claude-...`) and `auxiliaryModel`/`synthesisModel` is `cloudflare-workers-ai/...`, the provider guard sees only the primary model and skips validation. `CLOUDFLARE_ACCOUNT_ID` is never checked at startup and the user still hits the opaque runtime failure this PR aims to prevent.
View more details on @sentry/warden