Skip to content

fix(tui): expose workspace switching from providers pane #3112

Description

@johntmyers

User Story

As an OpenShell TUI user managing providers, I want to switch the active workspace while the Providers pane is focused, so that I can inspect and manage workspace-scoped providers without navigating to the Sandboxes pane first.

Problem Statement

The TUI has one dashboard-wide workspace selection, and changing it refreshes both providers and sandboxes. However, the w workspace shortcut is handled and advertised only while the Sandboxes pane has focus. The Providers pane has no visible workspace-switch action even though provider records are workspace-scoped.

This makes the provider UI appear gateway-global and obscures the isolation behavior implemented by #2243. Users must discover the non-obvious workaround of moving focus to Sandboxes, pressing w, and then returning to Providers.

Impact / Why This Matters

Providers contain workspace-owned credentials and may share the same name across workspaces. Hiding workspace selection from the Providers pane makes it difficult to understand which provider set is being displayed and increases the chance that users inspect or mutate the wrong workspace's provider.

The current workaround is insufficient because workspace is a dashboard-level scope, not a sandbox-only concept, and the title bar alone does not explain how to change it while working with providers.

Acceptance Criteria

  • Pressing w while the Providers pane is focused cycles the dashboard workspace using the same sequence and semantics as the Sandboxes pane.
  • The Providers navigation hints display [w] Workspace when workspace switching is available.
  • Switching workspace from Providers updates the title bar and refreshes both provider and sandbox lists.
  • Provider and sandbox cursor selections reset safely when the workspace changes.
  • The all workspace view remains supported, and provider creation continues to require selecting a specific workspace.
  • Tests cover workspace switching with Providers focused, including the pending refresh state and navigation hint.

Reproduction Steps

  1. Configure a gateway with at least two workspaces and providers in each workspace.
  2. Run openshell term.
  3. Focus the Providers pane.
  4. Observe that the navigation bar does not advertise a workspace action and pressing w has no effect.
  5. Move focus to Sandboxes and press w.
  6. Observe that the dashboard workspace changes and both sandbox and provider rows refresh.

Environment

  • OpenShell: current main at 07453f29
  • OS: all supported TUI platforms
  • Runtime, deployment, or integration: openshell term

Agent Investigation

The provider backend is already workspace-scoped. This issue is limited to TUI discoverability and input handling.

  • App::cycle_workspace changes the dashboard-wide scope, resets both sandbox and provider selection indices, and sets pending_workspace_refresh.
  • The event loop responds by refreshing both providers and sandboxes.
  • refresh_providers sends either the selected workspace or all_workspaces = true to ListProviders.
  • handle_sandboxes_key maps w to cycle_workspace, but handle_providers_key has no equivalent mapping.
  • The Sandboxes navigation bar advertises [w] Workspace; the Providers navigation bar does not.

Relevant locations:

  • crates/openshell-tui/src/app.rs: cycle_workspace, handle_providers_key, handle_sandboxes_key
  • crates/openshell-tui/src/lib.rs: pending workspace refresh handling and refresh_providers
  • crates/openshell-tui/src/ui/mod.rs: dashboard navigation hints

Alternatives Considered

A separate provider-only workspace selector would create two competing scopes on the same dashboard and allow provider and sandbox panes to show different workspaces. Reusing the existing dashboard-wide workspace selection preserves the current model and requires only exposing the existing action consistently.

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