You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
bug: provider update omits the existing provider type #2991
The agent inspected OpenShell main at ca61ee37440995d1ca17cb081f09c4743609cfff and reproduced the behavior against OpenShell 0.0.109 with an APF interceptor-backed provider profile.
provider_update fetches the existing provider only for --from-existing or --from-oidc-token, but always constructs UpdateProviderRequest.provider with:
The APF interceptor evaluates the request before the gateway merges it with stored state. It therefore cannot prove that the target is an APF-managed provider profile and denies a credential-only update. Initial provider creation succeeds; rotation fails.
Skills/instructions consulted: repository AGENTS.md, CONTRIBUTING.md, and .agents/skills/create-github-issue/SKILL.md.
Description
Actual behavior:openshell provider update NAME --credential ... sends an empty provider type and profile workspace. Policy interceptors that authorize mutations by provider profile reject the update.
Expected behavior: a credential-only update preserves the stored provider type and profile workspace in UpdateProviderRequest, allowing interceptors to authorize the same managed target without trusting caller-supplied replacement metadata.
Reproduction Steps
Configure an interceptor-provided signed profile such as agent-tool-gateway.
Create a provider from that profile.
Run openshell provider update NAME --credential KEY with the new value supplied through the environment.
Observe the interceptor receiving an empty provider type and denying the update.
Inspect crates/openshell-cli/src/run.rs::provider_update; the request initializes r#type and profile_workspace to empty strings.
Environment
OS: Ubuntu on Omnistation
Docker: OpenShell Docker driver
OpenShell: reproduced on 0.0.109; source behavior confirmed on main ca61ee37
Policy interceptor: APF signed provider profile source
Logs
UpdateProviderRequest provider.type = ""
APF cannot prove that the update target is bundle-managed; update denied
The report is technically valid. openshell provider update still constructs UpdateProviderRequest.provider with empty type and profile_workspace for ordinary credential/config updates. The gateway merges those immutable fields with stored provider state later, but request-time interceptors can observe the incomplete raw request and reject updates that need to prove the provider profile before the merge.
Investigation
Current main matches the reported code path: the CLI fetches existing provider metadata for --from-existing and --from-oidc-token, but not for plain --credential / --config updates. The update request then sends empty type and profile_workspace.
This is related to #1988 and PR #2962 because those cover the broader provider-profile model, including credentialless/runtime-resolvable profile behavior. It is not a duplicate: #2991 is specifically about preserving existing provider type/profile metadata on update requests so authorization/interceptor logic can evaluate the intended managed target before gateway-side merge semantics complete.
Impact Signals
Affected users/scope: Users rotating credentials for interceptor-managed provider profiles.
Regression: Unknown.
Workaround: Unknown; likely requires using a different update path or bypassing the interceptor-managed workflow.
Evidence quality: High; issue includes reproduction details and current source matches the reported request shape.
Human Decision Required
Decide whether OpenShell should address this issue. If yes, apply state:accepted, associate it with a roadmap item, or both.
Closing as fixed by #3109. That change preserves the stored provider type and profile workspace on credential updates before interceptor evaluation, and adds regression coverage for the request metadata. The PR used Refs rather than a closing keyword, so this issue remained open after the fix merged.
Activity
elezar commentedon Aug 28, 2026
natedemoss commentedon Sep 3, 2026
This was fixed by #3109, which merged earlier today. I used
Refsinstead ofClosesin that PR so it didn't auto-close this one.johntmyers commentedon Sep 17, 2026