Provider: Cline (ships native ACP, fits the existing adapter stack)

[kridaydave]

Proposal: add Cline as a provider

The ask: add a Cline driver alongside Codex / Claude / Cursor / Grok / OpenCode / Antigravity.

Why Cline

Cline has restructured itself over 2025–2026 from a VS Code extension into a layered TS agent stack, and now ships a standalone CLI (npm i -g cline, v3.x) with the same agent core. Users with Cline subscriptions or Cline account credits have no way to drive it from T3 Code today.

The integration surface that matters: native ACP

Cline supports three surfaces:

1. ACP — cline acp speaks Agent Client Protocol (JSON-RPC over stdio): initialize, session/new, session/load resume, session/prompt, session/cancel, streaming session/update, and session/request_permission (auto-approve defaults to false in ACP mode, so edit/command approvals surface to the client). Auth: Cline account OAuth via cline auth, non-interactive CLINE_API_KEY / CLINE_PROVIDER / CLINE_MODEL, or BYO keys (Anthropic, OpenAI, OpenRouter, Bedrock, …).
2. SDK (@cline/sdk, ~0.0.82) — rich in-process harness, but 0.x with likely API churn, and it runs in-process rather than as an isolated subprocess.
3. NDJSON one-shot mode (cline --json) — request/response, non-TTY runs deny approvals instead of surfacing them. Poor fit for an interactive host.

ACP is the right pick, and the reason the cost is low: this repo already has the shared ACP stack (packages/effect-acp + AcpSessionRuntime), and Grok, Cursor, and Antigravity already run on it. From the outside this looks like "one more driver on an existing pattern," not new architecture. Sessions persist and are resumable via session/load where supported.

Docs: https://docs.cline.bot/usage/acp · https://docs.cline.bot/cli/cli-reference.md · https://www.npmjs.com/package/cline

Rough shape of the work

• packages/contracts: a ClineSettings schema (settings form comes for free from the existing pattern).
• apps/server: acp/ClineAcpSupport.ts (spawn args, permission-mode mapping), a thin adapter on AcpSessionRuntime + the shared event mappers, driver registration in builtInDrivers.ts. First cut deliberately minimal: sessions, streaming, permission requests; honest capability flags (no rollback/resume claims unless proven). Probe uses ACP initialize only — no auth as a health-check side effect.
• Web + mobile: icon, label, settings entries.

Happy to split that into small, focused PRs (contracts → server driver → web → mobile) so nothing lands as a blob.

Questions for maintainers

• Is a sixth provider something you want direction-wise right now?
• If yes: any preference on auth UX (document cline auth vs a ProviderAuthController)?
• Native NDJSON vs ACP preference, or is ACP the obvious pick given the shared runtime?

Understood this is scope expansion, so this discussion comes before any code.

[kridaydave]

Main reason is that cline gives free models with generous limits for me to use :3