Env sync on `project add storage` finish errors out

[mcongrove]

matthewcongrove@Matthews-MacBook-Pro-Agentuity secops % bunx agentuity project add storage
✔ Select an organization · org_*
◇  Select a cloud region:
│  US Central
│
◇  Select a storage bucket to link
│  foobar
│
✓ Linked storage bucket: foobar
ℹ Environment variables written to .env
Sync environment variables to cloud project? [Y/n]
✗ Syncing environment variables to cloud: Not Found
⚠ Failed to sync environment variables to cloud. You can sync later with: agentuity cloud env push

[linear]

AGENT-1582

[Huijiro]

Fixed by 127f943 on v3.

What was wrong

agentuity project add storage was running the bucket's env map through two layers that were silently mis-handling it before reaching PUT /cli/project/{id}/env:

1. filterAgentuitySdkKeys treats any AGENTUITY_* key (outside a tiny allowlist + AGENTUITY_PUBLIC_*) as reserved and strips it. If/when the platform returns the canonical AGENTUITY_BUCKET_* keys, every one of them would be dropped before the cloud sync — local .env would look right, the cloud project would have nothing.
2. Today the platform actually returns raw AWS_* keys (AWS_ENDPOINT, AWS_BUCKET, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY). Those landed in .env verbatim, contradicting the storage manifest + @agentuity/storage (which expect AGENTUITY_BUCKET_*), and AWS_ACCESS_KEY_ID was being shipped as a plain env var rather than a secret — the suffix-based classifier in splitEnvAndSecrets only matches _KEY / _SECRET / _TOKEN / _PASSWORD / _PRIVATE, so _ID slipped through.

Fix (packages/cli)

• env-util.ts:
  • Added AGENTUITY_RESOURCE_PREFIXES = ['AGENTUITY_BUCKET_']; exempt those from isReservedAgentuityKey so they flow through filterAgentuitySdkKeys and splitEnvAndSecrets normally.
  • Added AWS_ACCESS_KEY_ID and AWS_SESSION_TOKEN to secretExactKeys.
  • Added normalizeBucketEnv() — translates raw AWS_* to canonical AGENTUITY_BUCKET_* (mirroring the SDK's resolveEndpoint host rule) and drops the AWS_* partners once the canonical trio is present, so projects don't end up with two parallel naming schemes.
• cmd/project/add/storage.ts and cmd/project/template-flow.ts: wrap the bucket env in normalizeBucketEnv on both the "Create New" and "Use existing" paths.

Tests added in packages/cli/test/config/env-util.test.ts covering classification + translation.

Caveat

The literal symptom in the original report was Syncing environment variables to cloud: Not Found — a 404 from PUT /cli/project/{id}/env. Our fix changes what gets sent (correct keys, correct env/secret split, no silent dropping) but doesn't directly target a 404 from the project endpoint. It's plausible the 404 was a downstream effect of the malformed payload, but if Not Found still shows up after upgrading to a build that includes 127f943, please reopen — that would point to a separate project-lookup bug, not this one.

Platform-side follow-up

Filed agentuity/infra#427 — the platform should return AGENTUITY_BUCKET_* directly, split per-resource env into { env, secrets }, and replace the untyped Record<string,string> shape with a proper typed response. The normalizeBucketEnv translation shim is a transition measure that can be removed once that lands.

[Huijiro]

Root cause of the Not Found confirmed and fixed by 8f5294e.

resolveRegion in packages/cli/src/cli.ts was checking the user's saved global region preference (config.preferences.region) before the project's own region. So for any project-scoped command, if the saved preference didn't match the project's actual region, the CLI would happily build a catalyst client for the wrong region and PUT /cli/project/{id}/env against a catalyst where that project doesn't exist \u2014 the API returns 404 and the CLI surfaces it as Syncing environment variables to cloud: Not Found.

In Matt's transcript:

\u25c7  Select a cloud region:
\u2502  US Central

\u2026 he was prompted to pick a region rather than the CLI just using the project's region directly. With a saved preference in place, the code reached getRegion(regions, matchingRegion.region) (interactive prompt defaulted to the preference) before the project-region branch even ran.

Reordered precedence to:

1. --region flag
2. cached resource region (id-driven)
3. auto-single-region
4. AGENTUITY_REGION env var
5. project region (was below preference)
6. saved preference
7. prompt / error

For project-scoped commands opts.region is now passed in as project?.region from the command harness, so the project's region is canonical and the cross-region 404 stops happening. The interactive prompt is also skipped for project-scoped commands when the project's region matches an available region.

Tests added in packages/cli/test/config/.../resolve-region.test.ts covering flag-vs-project-region, project-region-vs-preference, and preference fallback when no project region is set.