Idea: Adapt common cli`s

[schroejahr2]

Feature: CLI Selector with Auto-Detection & Model Switching

Example image attached.

Problem

The choice of coding agent CLI is currently static or requires starting in terminal. Different CLIs have different strengths (tool calling, language support, cost, speed), so we need a quick in-place switcher directly in the toolbar — including per-CLI model selection.

Components

1. CLI Picker (Toolbar Dropdown)

List of all installed and supported CLIs with status indicator:

2. Auto-Detection

On startup and manually via a refresh button in settings:

• which / where per CLI binary (claude, codex, opencode, cate)
• Version check via --version
• Platform-aware paths (Unix vs. Windows vs. WSL)
• Hide when nothing is detected.

3. Additional Settings Dialog

Per-CLI configurable:

• Binary path (override for non-standard installations)
• Default model
• Extra args / flags (e.g. --dangerously-load-development-channels)

4. Model Switcher

opens small model selection

Example :

CLI	Models
Claude Code	Opus 4.7 / Sonnet 4.6 / Haiku 4.5
Codex	gpt-5.5 / gpt-5.4-mini
OpenCode	dynamically read from opencode.json provider config
CATE	custom model list from user config

"Last used" is remembered per CLI.

|###
|##### Would build: eta: 2d
|###

[Anton-Horn]

Maybe worth to combine this with #122 and not just open CLI interface but going further and actually rendering the whole app there too.

[schroejahr2]

Quick note before we dive in — #122 (general "embed native apps in Cate" request) and the WIP PR #131 (Windows-only native-app panel). Worth treating them as two separate tracks because the scope and risk are very different.

Track A — CLI selector (this discussion, #126)

This is a contained feature with low platform risk. Most of the building blocks already exist:

• src/main/ipc/shell.ts already has AGENT_DEFINITIONS (Claude Code, Codex, Gemini, Cursor, OpenCode, Pi) — we can reuse that list as the dropdown source.
• TERMINAL_CREATE would need a new initialCommand option; right after ptySpawn we either write the command into the PTY or wrap the shell in -ic "<cli>; exec $SHELL" so the user falls back into their shell when the CLI exits.
• getShellEnv + resolveShell already give us the right $PATH for which/where lookups on every platform.

Realistic split:

1. Phase 1 — toolbar dropdown + spawn. Hardcoded list of CLIs from the existing AGENT_DEFINITIONS. Click → new terminal panel with the CLI as the initial command. No detection, no settings — just the quick win.
2. Phase 2 — auto-detection. Async parallel which / version probes through getShellEnv. Cache result, refresh button in settings, hide entries that aren't installed.
3. Phase 3 — per-CLI settings + model switcher. Binary override, extra args, default model with "last used" memory. Model lists vary per CLI: Claude is enumerable, Codex is enumerable, OpenCode reads its opencode.json, Pi has its own provider auth dialog already.

Independent of #122/#131 — nothing platform-specific.

Track B — native app embedding (#122, PR #131)

This is the much bigger one. The reply on #122 outlines the right plan (OS-level reparenting: SetParent on Windows, addChildWindow on macOS, XReparentWindow on X11). PR #131 takes a different, lighter approach for Windows and it's worth flagging the trade-offs before that approach becomes the de-facto pattern:

What #131 does

• Spawns the external app, enumerates top-level windows, matches by title pattern, then drives the discovered HWND with SetWindowPos (NOACTIVATE) to keep it positioned over the canvas region.
• Uses koffi FFI for the Win32 calls.

Concerns with this approach

• Not real embedding. Without SetParent (or WS_CHILD conversion), the app's window stays a peer in the OS z-order. The moment the user focuses any other app, the embedded window can fall behind Cate. Cate's own canvas pan/zoom doesn't propagate either — the window just sits on top.
• Title-pattern HWND discovery is fragile. Apps with generic titles ("Untitled — Notepad", "New Tab — Browser") or apps that spawn multiple top-level windows (Cursor's command palette, devtools) can match the wrong HWND, and there's no good signal to disambiguate.
• Focus competition. A peer window stealing focus on click means keyboard routing into Cate vs into the embedded app is brittle — same problem already flagged in the Add support for apps natively #122 thread.
• Pan/zoom sync. Canvas transforms aren't applied to the OS window; resizing the panel just moves the OS window without scaling it. For the canvas-as-spatial-workspace metaphor to hold, the embedded window needs to track zoom, which SetWindowPos alone won't do.
• Platform coverage. Code path is Windows-only and the abstraction it introduces (preset title patterns, single HWND per panel) doesn't obviously generalize to macOS NSWindow or Linux X11/Wayland.

It's a useful prototype to evaluate UX, but I'd land it explicitly as "experimental, Windows-only, peer-window mode" rather than as the foundation for a unified native-app panel. The eventual cross-platform implementation likely wants:

1. A native node addon per platform (not pure FFI) so we can hook WM_* / window-server callbacks.
2. True parent/child reparenting (or, on macOS, a custom NSView hosting the app's layer tree if reparenting isn't enough).
3. A separate discovery channel (process handle → window handle) instead of title matching.

Recommendation

• Ship Track A (Idea: Adapt common cli`s #126) first as three small PRs. It delivers immediate value, has no OS-specific code, and unblocks users who just want a quick way to spin up Claude/Codex/etc. without remembering binary names an will be able to set defaults.
• can integrate a "custom" setting to launch not covered commands / clis if needed.
• Keep Track B (Add support for apps natively #122/feat: add native Windows app panels #131) on its own timeline. Land feat: add native Windows app panels #131 as an experimental Windows-only path behind a setting, gather UX feedback, then design the real cross-platform abstraction once we know what the focus/sync model needs to look like.

Happy to start on Track A Phase 1 if there's interest.