feat: manage Claude Code and Codex plugins from Settings → Plugins

[Tryanks]

Summary

Tcode now surfaces each native CLI's own plugin system (Principle 1) on one Settings page. This PR covers the contract, the protocol and full lifecycle management for Claude Code and Codex. pi, OpenCode, Grok and Cursor follow in later PRs.

Settings → Plugins
  per provider profile
    context line (project or user-only)
    status (loading / stale / error verbatim)
    installed plugins
      per-scope sub-rows, only host-computed actions
      details (declared components, diagnostics)
    Add plugin picker
    marketplaces
  challenge dialogs (rendered from replicated state, survive reconnect)
    accept-command: CLI's own text, command, sha256
    destructive confirm: lists the uninstalls

crates/
├── agent/src/
│   ├── lib.rs                # ProviderPluginEntry, PluginAction, Caps.plugin_management
│   ├── claude_plugins.rs     # `claude plugin … --json` per operation
│   └── codex/plugins.rs      # temporary `codex app-server` per operation
├── protocol/                 # ProvidersStatus.plugins, 8 commands, PROTOCOL_VERSION 7 → 8
├── runtime/src/app/plugins.rs  # in-memory catalog per profile, one op at a time, challenge binding
└── ui/src/plugins_settings.rs  # the page above

Rules applied: every action runs through a non-interactive native path, never -y or --dangerously-bypass-hook-trust; native confirmations reach the user verbatim; TUI-only actions are skipped and say so. Native files remain the truth, the catalog is never persisted and is re-listed after every mutation.

Two findings worth knowing:

• The Claude management process strips CLAUDECODE, CLAUDE_CODE_ENTRYPOINT and CLAUDE_CODE_CHILD_SESSION. With them set the CLI silently ignores --accept-command (bisected per variable).
• Codex marketplace/remove leaves installed plugins active but unlisted, so Remove is only offered when nothing is installed from that marketplace.

Deviation from the plan, please confirm. The plan said "drop command cache pre-seeding". That would have removed / commands from a new thread's first message, so instead commands-<provider>.json is keyed by provider and native home and invalidated after a plugin change.

Evidence

• Before: no plugin management in Tcode; plugins had to be managed from each CLI's TUI.
  After: full Claude lifecycle (marketplace add, install user/project, command-source install → accept, disable/enable, update, uninstall, marketplace remove → confirm) and full Codex lifecycle driven from the desktop app against isolated homes. Screenshots reviewed in both themes at wide, narrow and compact geometry.
• Tests: Claude adapter on recorded fixtures (grouping by scope, challenge from the last JSON line, argv never auto-accepts); Codex adapter on recorded frames (requests carry cwds, never contain bypass flags, only the first-start sqlite race is retried); runtime with a fake claude (a stale challenge hash is refused; a plugin change invalidates only its home's cache); headless SettingsPage (only host-computed actions render, Accept answers exactly one op).

cargo fmt / clippy -D warnings / machete         ✓
cargo nextest run --workspace --locked           883 passed, 6 skipped
cargo check -p agent --no-default-features       ✓

Not run locally: iOS, Android, Web and Windows CI jobs.

Merge Danger

Door: two-way

Nothing is persisted by Tcode; native plugin files are the only state and are written by the CLIs themselves. Reverting removes the page and the protocol fields.

Blast Radius: protocol

• PROTOCOL_VERSION 7 → 8, so every client must update with the host. The branch is currently conflicting with main on that constant (feat: add Cursor and Grok as native providers over ACP dialects #584 and feat(orchestrate): move the bundled fleet into fleet.json #586 moved it since).
• Codex plugins installed from another project's repo marketplace stay invisible unless that repo is in cwds.
• Claude refresh runs one details call per installed plugin (~0.8 s each, 4 concurrent).
• Codex remote (openai-curated-remote) install and uninstall follow the schema only and were not exercised against a real account.

Update: master and per-provider switches (04bc273)

Settings gains a machine-owned plugins group: a master switch plus one switch per provider kind (keyed by the provider's settings key so a newer build's provider survives a load). Defaults: master on, Codex on, every other provider off; an untouched settings.json stays free of the key.

Off means Tcode never touches that CLI's plugin state: refresh is accepted as a no-op, no plugin process or app-server is started, mutations and challenge answers are rejected with plugin_management_disabled, a pending challenge is abandoned, the catalog is forgotten and omitted from ProvidersStatus.plugins. Switching on refreshes from the page (which owns the project context). The page shows the master switch at the top and a switch in each section; an off section collapses to its header and one line.

Tests: runtime (default Claude off → refresh starts no process and install is refused; patch on → lists; patch off → catalog gone and the old challenge is unknown), core (literal legacy JSON and partial plugins objects, unknown provider key tolerated, master off wins), UI headless (off section renders only its switch; clicking it patches settings; replicated settings trigger a refresh and show Add). Checks on the committed tree in a clean worktree: fmt ✓, clippy ✓, nextest 885 passed / 6 skipped, machete ✓.

Update: Tcode computer use is not attached to Codex (cd39b87)

codex features list on 0.159.3 reports computer_use stable, so Codex has its own computer use. Per Principle 1, Caps.native_computer_use withholds the tcode_computer_use registration (and its token) from Codex sessions; preview/orchestrate/report are unchanged. Settings → Computer Use, the provider card and the provider picker show "Codex has its own computer use; Tcode's computer-use tools are not attached." The existing session_launch_preserves_approval_policy_and_scopes_mcp_registrations test now asserts Codex gets no computer-use registration while Claude does. Checks on the committed tree in a clean worktree: fmt ✓, clippy ✓, nextest 885 passed / 6 skipped, machete ✓.

Note on CI: GitHub recorded no pull_request workflow runs for this PR's pushes; the PR was closed and reopened to trigger the workflow.

Update: merged main (53be54b)

Main added the Cursor and Grok provider kinds and Principle 9 (the protocol version is bumped at release, never in the PR). Resolution: PROTOCOL_VERSION stays at main's 9 with the wire change recorded as // Unreleased: provider plugin catalogs, their commands, challenges and switches. (our earlier 7→8 bump is withdrawn). Cursor and Grok caps rows get plugin_management: NONE and native_computer_use: false (no verified evidence; Grok's plugin CLI is mapped in the plan but its adapter is not implemented), their command caches use the per-home key, and the computer-use note iterates ProviderKind::NATIVE instead of a hand-written list. Checks on the merge commit: fmt ✓, clippy ✓, cargo check -p agent --no-default-features with -D warnings ✓, nextest 907 passed / 6 skipped, machete ✓.

Wire change: yes (ProvidersStatus.plugins, eight plugin commands, plugin toasts, settings plugins group) — noted under Unreleased per Principle 9.