Skip to content

Per-tab AI agent: run a different agent (e.g. Gemini and Claude) in each tab #295

Description

@frarteaga

Description of the new feature

Allow each tab to run its own AI agent simultaneously — e.g. Gemini in one tab and Claude in another, in the same window.

Today the agent (acpAgent) is a single process-global setting, so every agent pane in every tab/window is forced onto the same agent CLI. Switching the agent changes it for the whole window (and tears down every agent pane via _RebuildAgentStack). Different tasks suit different agents/models, and you often want a second tab driven by a different agent without spinning up a separate Terminal process.

Desired behavior:

  • Each tab can pick its own agent (and model); newly opened tabs follow the global default.
  • Switching one tab's agent affects only that tab — sibling tabs keep their agent, session, and chat history.
  • Changing the global default only re-applies to tabs that haven't picked their own agent.
  • Per-tab selection stays GPO-aware (respects AllowedAgents / AllowCustomAgents).

Acceptance criteria:

  • Tab A on Gemini and Tab B on Claude, live, in the same window.
  • wta-main_master.log shows two distinct agent CLI spawned lines (one per agent) running concurrently.
  • wta sessions list reports the correct per-session CLI (Gemini vs Claude) — per-agent cli_source, not one process-wide value.
  • Killing one agent CLI only disconnects its tab; the other keeps working and the master survives.

Proposed technical implementation details

The event plane is already per-tab (agent_status / agent_state_changed carry tab_id; the agent-bar label/logo are per-pane), and doc/specs/Multi-window-agent-pane.md §9 already calls this out as the intended evolution: "master spawns a pool of agent CLIs keyed by agent_id."

Two structural blockers today:

  • C++: agent reads (_BuildSharedWtaExtraArgs, _AutoCreateHiddenAgentPaneShared, _CaptureAgentSettingsSnapshot) all pull from GlobalAppSettings; the agent is global-only.
  • Rust wta-master: spawns one agent CLI at startup (spawn_agent_process(&cli.agent)), does one initialize, caches one response, and multiplexes every helper onto that single connection — it cannot talk to two different agent CLIs at once.

Proposed approach:

  • Make wta-master a lazy multi-agent broker: a pool keyed by the agent command line, spawning/reusing one agent CLI per distinct command line, driven by what each tab's helper declares in the ACP initialize handshake (_meta.wta.agent_cmd / agent_id). Per-agent cached initialize response + resolved cli_source. A dead agent CLI is reaped from the pool without killing the master.
  • Add a runtime-only per-tab agent override on Tab (agent id + model), set via a flyout on the agent-bar chip, populated from the GPO-filtered agent list. Switching rebuilds only that tab's pane (no master restart). The global-default-change path skips overridden tabs.

(Runtime-only override — not persisted across restarts — is a reasonable first cut.)

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions