Question: are CLI-backed subscription providers (Claude Code, Codex) on the roadmap?

Question

Are you considering letting AI chat run on a user's existing Claude or ChatGPT subscription by driving the local claude / codex CLI, alongside the BYOK API keys? If it's something you'd accept, I'd like to help with a PR. If it's out of scope, that's a useful answer too and I'll stop here.

This stays within the BYOK principle in AGENTS.md: the credential is still the user's own login, and Reflect never operates AI infrastructure.

Why

• Many users already pay for Claude Pro/Max or ChatGPT Plus/Pro and have the CLI installed. Per-token API billing on top is a second bill for the same models.
• Spawning the official CLI is the sanctioned path. Anthropic's April 2026 change blocked third-party harnesses that reuse Claude Code's OAuth token, but claude -p as a subprocess is unaffected. Codex has an explicit non-interactive mode (codex exec --json) and an experimental app-server JSON-RPC surface meant for embedding.
• The README already positions Reflect as "AI agent-friendly", and #1143 adds permissioned tools + privacy revalidation. A CLI backend would slot into that same tool/privacy boundary.

What I verified (no core changes)

Claude Code. With the openai-compatible provider pointed at a local proxy that wraps claude -p (claude-max-api-proxy), chat works end-to-end on a Max subscription: Reflect's system prompt goes through, streaming works, and --model claude-fable-5-1 / claude-opus-5 are honoured when the proxy passes the id through verbatim.

Codex. codex exec --json --ephemeral --ignore-user-config -s read-only -m gpt-5.6-sol answers on a ChatGPT login with structured JSONL (thread.started / item.completed / turn.completed with usage). Two caveats: exec --json emits completed items rather than token deltas, so token streaming would need app-server; and Codex's own system prompt costs ~15k input tokens per turn (mostly cached).

Two things don't work through a generic proxy, and they're why I'm asking rather than just documenting the workaround:

1. Tools don't round-trip. Neither CLI accepts ad-hoc tool definitions from the request, so search_notes / read_notes / list_daily_notes / list_recent_notes never reach the model. The model correctly answers "the Reflect note tools aren't available in this session". Chat works; "what did I write last week?" doesn't.
2. A naive subprocess leaks the user's environment. By default both CLIs attach every MCP server in the user's global config (for me: 39 tools across 6 servers on the Claude side, including screen-capture history and Google Drive; browser/computer-use servers on the Codex side) plus their own file/shell tools. Reflect's CloudSafe gate only covers tool output, so a subprocess that can read the graph folder directly would bypass private: true. This has to be closed by construction:
   • Claude: --tools "" --strict-mcp-config --mcp-config <reflect-only>
   • Codex: --ignore-user-config -s read-only -c mcp_servers.reflect.command=… (config overrides are accepted per run; I verified they're honoured)

Sketch, if you're open to it

• New provider kinds (claude-code, codex) in aiProviderIdSchema, no key; the settings UI shows CLI detection (claude --version / codex --version). Desktop only; mobile keeps BYOK.
• One Rust spawn command for CLI subprocesses (std::process or tauri-plugin-shell), streaming stdout lines back to core.
• Core exposes the existing chat tools (and #1143's write tools under the same permission mode) to the subprocess as a single stdio MCP server, launched with the flags above so only Reflect's tools exist. The CloudSafe / privacy revalidation path stays exactly where it is because tool execution still happens inside core.
• stream-chat.ts gets a second backend that normalises the CLI event streams (stream-json for Claude, exec --json / app-server for Codex) into the existing ChatStreamEvent union.

Smaller, independent nicety: the openai-compatible provider could offer the server's /v1/models list instead of one model string per entry. Today each model needs its own provider entry.

Happy to write any of this up in more detail, or drop it if it doesn't fit the direction.

Start by reading AGENTS.md, the aiProviderIdSchema definition, and stream-chat.ts to understand the existing provider and event boundaries. Then review the proposed subprocess, MCP, privacy, and settings changes; done would mean a scoped roadmap decision or an accepted implementation plan, not just a generic proxy workaround.