[feloy]

Summary

Make imported provider profiles authoritative for non-secret environment defaults and discovery. Preserve sandbox environment precedence and Vertex credentials during migration from the legacy service-account key. Configure Google SDK access to the existing supervisor metadata service through declarative profile settings.

Related Issue

Closes #3442.

Changes

• Add bounded profile declarations for projected and fixed environment values and discovery config keys, with deterministic profile serialization and updated Go bindings.
• Replace provider-ID-selected Google Cloud and Vertex environment setup in the gateway with profile declarations while preserving caller environment values and credential placeholders in main and exec processes.
• Keep the supervisor-backed GCP metadata relay restored by main in f7273e4. The google-cloud profile declares the metadata host, IP, and detection environment values used by Google SDK discovery. The service is available in Linux sandboxes using Docker, Podman, Kubernetes, or VM; Windows/MXC does not provide it. Profile import and attachment do not enable the service or validate its availability.
• Reject GOOGLE_SERVICE_ACCOUNT_KEY as an injectable credential or non-secret default. Older stored provider records can retain it without withholding the access token and SDK configuration.
• Allow two attached providers to share a non-secret destination when their values match; reject differing values and overlapping credential keys. Update regression tests, examples, architecture docs, provider guides, and migration notes.
• Restore the GCP token-response helper and its tests, and import the GCP profile in the provider E2E setup.

Testing

• mise run pre-commit passed before the rebase; the final commit's hooks passed after the rebase
• mise run ci passed before the rebase
• Unit tests added/updated and focused post-rebase tests passed
• E2E tests added/updated and focused post-rebase lanes passed

After the rebase, core and provider tests, focused gateway tests, supervisor-network GCP metadata tests, and the restored token-response tests passed. mise run test:e2e-provider-profiles passed, as did all three Google SDK metadata-discovery cases in the Podman sandbox E2E suite. The metadata relay, supervisor handler, proxy, and core metadata protocol code match main; the imported profile configures SDK discovery for that existing runtime path.

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[github-actions]

Label test:e2e applied, but pull-request/3775 does not exist yet. A maintainer needs to comment /ok to test 5e32a9462576ccf25ba7a12ea98dc18e36576fe7 to mirror this PR. Once the mirror exists, re-apply the label or re-run Branch E2E Checks from the Actions tab.

[johntmyers]

/ok to test 5e32a94

[johntmyers]

gator-agent

PR Review Status

This provider-boundary change is project-valid under linked issue #3442 and its pre-0.1.0 roadmap. The independent initial review found no blocking defects, and the required current-head branch, Helm, and E2E workflows are queued after creating the PR mirror.

Blocking findings:

• No blocking findings remain

Carried findings:

• None

Gator metadata

• Validation: Implements the defined provider-boundary work in #3442 under roadmap #3171 and the coordinated pre-0.1.0 effort #2565
• Docs: Fern provider and migration docs, provider examples, and architecture documentation are updated
• Checks: Current-head Branch Checks and Helm Lint workflows are queued
• E2E: test:e2e applied; /ok to test created the current-head mirror and Branch E2E Checks is queued
• Head SHA: 5e32a9462576ccf25ba7a12ea98dc18e36576fe7
• Base SHA: eef8bec0c96b384556d608f8d899a8a96f5d17a1
• Merge base SHA: 9f60f55c6b0811b1651099b50e4618d435ebc02e
• Patch ID: b24a544279787e3a990b12da55d77491e4d6bd1d
• Gator payload: 9
• Review mode: initial
• Previous reviewed SHA: none
• Review budget exhausted: no
• Maintainer decision required: no
• Next state: gator:watch-pipeline

[johntmyers]

/ok to test 8e48662

[johntmyers]

gator-agent

PR Review Status

The follow-up review checked the new endpointless-provider E2E coverage added since the prior reviewed head and found no blocking defects. The current-head mirror is now updated, and the required branch, Helm, and E2E workflows are queued.

Blocking findings:

• No blocking findings remain

Carried findings:

• None

Gator metadata

• Validation: Implements the provider-boundary work defined by linked issue #3442 under the coordinated pre-0.1.0 roadmap
• Docs: Existing Fern provider and migration docs remain sufficient; this follow-up delta changes only E2E coverage
• Checks: Current-head Branch Checks and Helm Lint workflows are queued
• E2E: test:e2e remains applied; /ok to test updated the mirror and current-head Branch E2E Checks is queued
• Head SHA: 8e48662edf04d770f1dfe1eaf5c4d1efb7a92b57
• Base SHA: eef8bec0c96b384556d608f8d899a8a96f5d17a1
• Merge base SHA: 9f60f55c6b0811b1651099b50e4618d435ebc02e
• Patch ID: 9ff76bb05f61eeef8087be0b1cbec4c271e650bc
• Gator payload: 9
• Review mode: follow_up
• Previous reviewed SHA: 5e32a9462576ccf25ba7a12ea98dc18e36576fe7
• Review budget exhausted: no
• Maintainer decision required: no
• Next state: gator:watch-pipeline

[johntmyers]

/ok to test ab90b18

[feloy]

I have updated the user documentation which was incomplete

[johntmyers]

/ok to test baef723

[feloy]

@johntmyers @drew I wonder about the support of GCP metadata emulator. The implementation has been removed by PR #2942 (google_cloud_metadata.rs and metadata_server.rsremoved) but I cannot find the issue justifying this removal. Should the documentation completely remove references to it?

[drew]

@johntmyers @drew I wonder about the support of GCP metadata emulator. The implementation has been removed by PR #2942 (google_cloud_metadata.rs and metadata_server.rsremoved) but I cannot find the issue justifying this removal. Should the documentation completely remove references to it?

Can you file a bug to add it back? This was likely done in error and missed if there were no E2E tests.

[drew]

I'd also like to note that we can't merge this PR (#3775) unless we make it backwards compatible. Breaking changes need to get slotted into the 0.2.0 release.

[feloy]

@johntmyers @drew I wonder about the support of GCP metadata emulator. The implementation has been removed by PR #2942 (google_cloud_metadata.rs and metadata_server.rsremoved) but I cannot find the issue justifying this removal. Should the documentation completely remove references to it?

Can you file a bug to add it back? This was likely done in error and missed if there were no E2E tests.

I have created #3860

[johntmyers]

gator-agent

PR Review Status

Thanks @feloy, I checked your rebased author series against the last reviewed head. Five commits remain patch-equivalent; the remaining differences adapt to upstream credential-owner changes and updated schema fingerprints and Go bindings. The bounded Critical-only review found no newly introduced Critical defect, and the resolved Claude executable guidance remains intact. @drew's compatibility requirement remains unresolved: existing Google profiles still need new environment and discovery declarations to preserve their behavior.

Action required: @feloy, preserve compatibility for the current release or defer the breaking behavior to 0.2.0 as @drew directed. A maintainer also needs to approve the current-head Trivy workflow.

Blocking findings:

• No new Gator code-review blockers on this delta.

Carried findings:

• GATOR-baef7232-01: resolved; its executable guidance and maintainer-resolved thread are preserved.
• Maintainer requirement: backward compatibility remains unresolved.

The current-head test mirror is refreshed. Branch Checks, Helm Lint, E2E, and Windows MSVC are queued; their results will show whether the earlier failures recur.

Gator metadata

• Validation: Implements the provider-boundary work defined by linked issue #3442.
• Docs: Fern provider and migration documentation retained; existing Google profiles require migration.
• Checks: DCO passed; Branch Checks and Helm Lint queued; Trivy requires maintainer workflow approval.
• E2E: test:e2e retained; current-head /ok to test refreshed the mirror and Branch E2E Checks is queued.
• Windows: test:windows retained; Windows MSVC is queued.
• Head SHA: 367047a6d0f130edbb806c83acbffa753da73622
• Base SHA: 67adcf1a3cf054be54dfdbf6a44c65b4d426b1ec
• Merge base SHA: 67adcf1a3cf054be54dfdbf6a44c65b4d426b1ec
• Patch ID: abec1acfcc518f6fa14565426a5bc98ecd926337
• Gator payload: 10
• Review mode: critical_only
• Previous reviewed SHA: 27575147034ae4f1ea6047a39166057b828f3944
• Review budget exhausted: yes
• Maintainer decision required: no — the existing compatibility direction is clear; workflow approval is a separate process action.
• Next state: gator:blocked
• Blocked reason: workflow_approval_required

[feloy]

• branch rebased on main after merge of fix(windows): restore MSVC lint for CLI and MXC #4194: the test/windows failures should be fixed
• The related issue refactor(providers)!: make provider behavior explicit in imported profiles #3442 targets milestone 0.2.0

[rhuss]

Heads-up: the Go SDK moves to ai-openshell/sdk-go on 2026-11-03 (#5031). This PR also changes hand-written SDK code under sdk/go/openshell/. Please keep it in the PR, since core still builds sdk/go until its Go CI gate is dropped. After the freeze, sdk/go here is a deprecated snapshot. Once this PR merges and its protos ship in a core release, the SDK part gets ported to sdk-go with your authorship. Nothing to do on your side.

[feloy]

Could I have review on this PR targeting next release?

[krishicks]

Written by Claude Code, reviewed by @krishicks

Upgrade docs belong in a 0.2.0 guide

The Google migration text is appended to docs/upgrade/0-1-0.mdx, which is for a release that has already shipped. Move it to a new docs/upgrade/0-2-0.mdx with a docs/index.yml entry. Also describe what operators see if they don't migrate. A stored google-cloud or google-vertex-ai profile without an environment block still attaches without error. Its sandboxes get only the token placeholders: no project, region, GOOSE_PROVIDER/ANTHROPIC_VERTEX_PROJECT_ID, or GCE_METADATA_HOST. SDKs then fall back to 169.254.169.254, which is blocked. Nothing at attach time or in logs points to the cause.

required_platform_adapter doesn't enable or gate anything at runtime

• ensure_platform_adapter_available (crates/openshell-providers/src/profiles.rs:851) checks cfg!(windows) on the gateway binary. Nothing in the supervisor reads the field.
• The metadata relay is always on for Linux sandboxes (crates/openshell-supervisor-network/src/proxy.rs:693).
• The env vars that point SDKs at the relay come from environment.fixed, so any profile can set GCE_METADATA_HOST without declaring the adapter.
• The check measures the gateway's platform, but the capability belongs to the sandbox runtime. A Linux gateway driving MXC sandboxes would accept the profile.

Two options:

• Have the adapter own its env, so declaring gcp-metadata injects the metadata host, IP and detection values. 127.0.0.1:8174 is currently duplicated between providers/google-cloud.yaml and openshell_core::google_cloud. Check availability against a capability the compute driver or supervisor advertises, not the gateway's platform.
• Or drop the field and document the requirement in the example profile's header.

Caller-set GCP_PROJECT_ID makes the metadata emulator return 404 for project-id

When the sandbox spec or template sets GCP_PROJECT_ID, the caller-wins filter (crates/openshell-server/src/grpc/policy.rs:3976) drops that key from the snapshot, and with it from non_secret_environment_keys. The emulator only reads classified non-secret values (crates/openshell-supervisor-network/src/google_cloud_metadata.rs:219), so /computeMetadata/v1/project/project-id returns 404 "not configured as non-secret".

GOOGLE_CLOUD_PROJECT is still injected with the provider's value. The workload ends up with GCP_PROJECT_ID=<caller>, GOOGLE_CLOUD_PROJECT=<provider>, and a metadata server that knows neither. Most SDKs read GOOGLE_CLOUD_PROJECT first, so the impact is mostly limited to clients that ask the metadata server for the project directly (e.g. Go metadata.ProjectID()). Your call on whether to address it. Options: keep provider values in the supervisor's non-secret map and drop them only from the child env, have the emulator fall back to the caller value, or document it.

Denylist for profile-declared env keys

valid_environment_key (crates/openshell-providers/src/profiles.rs:3237) checks only syntax and the revision namespace. That doesn't change the trust tier: profile import already requires workspace admin, and files[].env_var can already name arbitrary vars. But environment.fixed widens the possible values to things like NODE_OPTIONS=--require …, LD_PRELOAD, PATH, or OPENSHELL_*. Consider one denylist shared by environment.* and files[].env_var, covering at least:

• OPENSHELL_*, LD_*, DYLD_*, PATH, BASH_ENV, ENV
• NODE_OPTIONS, PYTHONPATH, PYTHONSTARTUP
• the proxy vars, the TLS trust vars, and OTEL_EXPORTER_*

This could be a follow-up issue instead.

Smaller items

• The trailer on ef4a2c4 still says the gcp-metadata adapter is "currently unavailable".
• The docs now tell users to copy chosen profiles into a separate directory instead of running import --from providers, because imports are atomic and the gcp-metadata example fails on Windows. State that tradeoff in the 0.2.0 guide.
• GOOGLE_SERVICE_ACCOUNT_KEY is now withheld for every profile ID, not just google-vertex-ai. A custom fork that relied on injecting it loses it, and the only trace is a gateway warn!. Mention this in the migration notes.

[krishicks]

Written by Claude Code, reviewed by @krishicks

The rebases on b8cfb96 and 1b8a2a2 resolve conflicts with main, but the review items from the earlier review are still open:

• 0.2.0 upgrade guide: the Google migration notes are still in docs/upgrade/0-1-0.mdx.
• required_platform_adapter: still a gateway-side cfg!(windows) check that gates nothing at runtime.
• Caller-set GCP_PROJECT_ID: the emulator still returns 404 for project-id. Your call whether to change it or document it.
• Env key denylist: not added. A follow-up issue is fine.
• Migration notes: they still don't cover the import --from tradeoff, or that GOOGLE_SERVICE_ACCOUNT_KEY is now withheld for every profile ID.

The stale "currently unavailable" trailer is fixed.

New since the last review: #5245 froze sdk/go/. Branch Checks now rejects PRs that add or change files under it (.github/workflows/branch-checks.yml:624). This PR still changes six files there, including the regenerated openshell.pb.go. Drop them. Per the check's message, regenerated bindings aren't needed, and sdk-go ports SDK changes from core releases.

[feloy]

Thanks @krishicks. The review changes are now included through df02e79:

• 0.2.0 upgrade guide: moved the Google migration notes out of the shipped 0.1.0 guide and added the 0.2.0 guide to navigation. It explains why the declarations are needed, the symptoms without migration, and includes custom-profile examples (7ac9c17).
• Runtime requirements: removed required_platform_adapter and the gateway-platform check, reserving the retired protobuf field. The example profile, provider docs, and upgrade guide now describe the Linux sandbox requirement and clarify that import and attachment do not validate metadata runtime support (24efcc8).
• Caller-set project ID: retained effective caller values in the classified non-secret snapshot, with sandbox environment > template environment > provider default precedence. Explicit empty values are preserved, effective overrides participate in the revision, and credential ownership is unchanged. Metadata now sees the effective GCP_PROJECT_ID; docs explain that project aliases are resolved independently (df02e79).
• Migration details: documented atomic batch imports and the recommendation to import a reviewed subset. Also documented that GOOGLE_SERVICE_ACCOUNT_KEY is withheld across all profile IDs, including custom forks, with steps and examples for migrating to gateway-managed refresh.
• Frozen Go SDK: removed all six Go SDK changes and restored the frozen snapshot (0d61fd5).
• Environment-key denylist: deferred to a separate follow-up, as suggested. That work should define a shared restriction for environment.config, environment.fixed, and files[].env_var, including compatibility handling for existing custom profiles.

For the value-handling fix, 73 focused Rust tests and all six Google SDK metadata-discovery E2E cases passed in Podman. Commit hooks, Clippy, and documentation checks passed; Fern reports three existing warnings.