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
openshell term
- Providers screen → Create Provider
- Type:
anthropic, fill in ANTHROPIC_API_KEY=sk-ant-…
- Save.
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
- 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.
- Plumb the populated map into the two
spawn_* functions in place
of HashMap::default().
- 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.
Summary
The TUI's "Create Provider" and "Update Provider" forms accept
credentials but provide no UI or code path for the provider's
configmap. As a result, providers authored viaopenshell termalways carry an empty
config, which makes it impossible to use theTUI 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) handlesthis correctly — only the TUI surface is affected.
Reproduction
openshell termanthropic, fill inANTHROPIC_API_KEY=sk-ant-…openshell provider get <name>— observeconfigis 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 formsends an empty map; see source below).
Source location (upstream
mainat 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
configmap; the form structs themselves don't carry config-keystate at all.
Expected
The Create/Update Provider forms should expose the same
configmapthe CLI's
--configflag exposes — likely as a section parallel tothe 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
configfrom thefetched provider rather than overwriting with empty (current behavior
is destructive — TUI-edit of an existing provider wipes its
URL/config).
Why it matters
anthropic/openai/etc. provider at anon-default URL (in-cluster proxy, regional endpoint, custom
router, BYO inference gateway) cannot be configured or maintained
through the TUI.
who edits credentials on an existing provider unknowingly removes
its
ANTHROPIC_BASE_URL.Suggested fix sketch
CreateProviderForm/UpdateProviderFormwith aconfig: Vec<(String, String)>(orIndexMap<String, String>) and reusethe same UI patterns the credentials section uses for keyboard
add/edit/remove.
spawn_*functions in placeof
HashMap::default().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.