Skip to content

bug: provider update omits the existing provider type #2991

Closed

Description

@slopp

Agent Diagnostic

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:

r#type: String::new(),
profile_workspace: String::new(),

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

  1. Configure an interceptor-provided signed profile such as agent-tool-gateway.
  2. Create a provider from that profile.
  3. Run openshell provider update NAME --credential KEY with the new value supplied through the environment.
  4. Observe the interceptor receiving an empty provider type and denying the update.
  5. 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

Activity

  1. elezar commented on Aug 28, 2026

    @elezar
    Member

    📋 triage-agent

    Triage Assessment

    Classification: validated-bug

    Summary

    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.

    Recommended labels: area:cli, area:providers, area:gateway, state:validated.

  2. natedemoss commented on Sep 3, 2026

    @natedemoss
    Contributor

    This was fixed by #3109, which merged earlier today. I used Refs instead of Closes in that PR so it didn't auto-close this one.

  3. johntmyers commented on Sep 17, 2026

    @johntmyers
    Collaborator

    📋 triage-agent

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions