Skip to content

TUI: provider create/update form cannot set config keys (e.g., ANTHROPIC_BASE_URL) #1798

Closed

Description

@st-gr

Summary

The TUI's "Create Provider" and "Update Provider" forms accept
credentials but provide no UI or code path for the provider's
config map. As a result, providers authored via openshell term
always carry an empty config, which makes it impossible to use the
TUI to author a working provider that points at any non-default
upstream URL (e.g., ANTHROPIC_BASE_URL, OPENAI_BASE_URL,
custom-routed proxy endpoints, in-cluster bridges, etc.).

The CLI (openshell provider create --config KEY=VALUE) handles
this correctly — only the TUI surface is affected.

Reproduction

  1. openshell term
  2. Providers screen → Create Provider
  3. Type: anthropic, fill in ANTHROPIC_API_KEY=sk-ant-…
  4. Save.
  5. openshell provider get <name> — observe config is empty
    (no ANTHROPIC_BASE_URL).

Same applies to the Update Provider form for an already-created
provider: editing it via TUI clobbers the config (since the form
sends an empty map; see source below).

Source location (upstream main at time of writing)

crates/openshell-tui/src/lib.rs:

  • spawn_create_provider (~L1581) — line ~L1619:
    config: HashMap::default(),
  • spawn_update_provider (similar) — line ~L1711:
    config: HashMap::default(),

In both spots the proto request is built with an unconditionally-empty
config map; the form structs themselves don't carry config-key
state at all.

Expected

The Create/Update Provider forms should expose the same config map
the CLI's --config flag exposes — likely as a section parallel to
the existing credentials section in the form, with the same
add/edit/remove key/value affordances.

For the Update form specifically: until the field is editable, the
form should at least preserve the existing config from the
fetched provider rather than overwriting with empty (current behavior
is destructive — TUI-edit of an existing provider wipes its
URL/config).

Why it matters

  • Any setup that points an anthropic/openai/etc. provider at a
    non-default URL (in-cluster proxy, regional endpoint, custom
    router, BYO inference gateway) cannot be configured or maintained
    through the TUI.
  • The Update Provider clobber is silently destructive — a TUI user
    who edits credentials on an existing provider unknowingly removes
    its ANTHROPIC_BASE_URL.

Suggested fix sketch

  1. Extend CreateProviderForm / UpdateProviderForm with a config: Vec<(String, String)> (or IndexMap<String, String>) and reuse
    the same UI patterns the credentials section uses for keyboard
    add/edit/remove.
  2. Plumb the populated map into the two spawn_* functions in place
    of HashMap::default().
  3. For the Update form, hydrate the new field from the fetched
    provider on form open, so the in-memory edit is non-destructive
    even if the user doesn't touch it.

Happy to take a stab at this if it's a useful contribution.

Activity

  1. letv1nnn commented on Jul 7, 2026

    @letv1nnn
    Contributor

    Hey @st-gr, I'd like to take this on.

  2. letv1nnn commented on Jul 10, 2026

    @letv1nnn
    Contributor

    Hey @st-gr, I've implemented the missing TUI features and created a PR on my fork, would appreciate a review when you get a chance.

  3. TaylorMutch commented on Jul 11, 2026

    @TaylorMutch
    Collaborator

    Hey @letv1nnn this looks great - would you be open to contributing this back? If you submit a vouch request I can approve you

  4. added
    retired:area:tuiRetired; do not apply. See #5151 for item-specific migration to the current taxonomy.
    retired:area:providersRetired; do not apply. See #5151 for item-specific migration to the current taxonomy.
    and removed
    state:triage-neededOpened without agent diagnostics and needs triage
    on Jul 11, 2026
  5. added theissue type on Jul 11, 2026
  6. letv1nnn commented on Jul 11, 2026

    @letv1nnn
    Contributor

    Hey @TaylorMutch, I've opened the PR upstream, PTAL.

  7. github-actions commented on Aug 30, 2026

    @github-actions

    This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.

  8. st-gr commented on Aug 30, 2026

    @st-gr
    ContributorAuthor

    Closing — this was implemented and merged in #2224, "feat(tui): add config key support to provider create/update forms" (merged 2026-07-22). Thanks @letv1nnn for picking it up and seeing it upstream, and @TaylorMutch for the vouch.

    Verified on main: the provider create/update form now carries the config key/value input, with the original example from this issue named in the doc comment.

    // crates/openshell-tui/src/app.rs:380
    /// Provider config key-value pairs (e.g. `ANTHROPIC_BASE_URL`).
    

    Sorry for leaving this open five weeks after it was fixed — the stale bot prompted the tidy-up.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    retired:area:providersRetired; do not apply. See #5151 for item-specific migration to the current taxonomy.retired:area:tuiRetired; do not apply. See #5151 for item-specific migration to the current taxonomy.state:staleInactive item at risk of automatic closure.

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions