Support authenticated Codex CLI and Claude Code runtime providers

[seanpianka]

Problem

Asyar's OpenAI and Anthropic providers currently require API keys and separately billed API usage. I already have Codex and Claude Code authenticated on my Mac through their official account login flows.

T3 Code handles this by controlling the installed, authenticated provider runtimes rather than treating subscription credentials as general API keys. For launcher use cases such as quick questions, translation, and silent selected-text transformations, local models are currently the only Asyar option that avoids duplicate API billing.

Proposal

Add optional external-runtime provider adapters:

• Codex: use the installed Codex CLI/app-server through its supported interface and existing codex login session.
• Claude: use a supported Claude Code runtime interface and existing claude auth login session, if Anthropic's current third-party policy permits it.
• Discover runtime and authentication status rather than importing credentials.
• Support streaming, cancellation, provider errors, and visible subscription-limit failures.
• Keep the current direct API-key, Ollama, and OpenAI-compatible providers unchanged.

Security and policy boundaries

• Do not read, copy, export, or persist OAuth tokens or browser cookies.
• Do not impersonate an official client or route direct third-party requests against subscription endpoints.
• Delegate authentication and model requests to the user's official installed runtime.
• Clearly label that these are agent runtimes, so behavior, latency, tools, models, and usage limits may differ from direct model APIs.

Question

Would authenticated external-runtime providers fit Asyar's current provider architecture? If so, would the maintainers prefer starting with Codex app-server as the narrower first implementation?

[seanpianka]

I dug through the current provider path because I initially assumed this would mostly be another provider configuration. It isn't. Asyar's current provider seam is specifically an HTTP seam:

agents/runner.rs
  -> ai_stream_chat_impl()
  -> providers::build_request()
  -> reqwest
  -> SSE or NDJSON parsing

AgentRunner calls ai_stream_chat_impl, which builds an HTTP RequestSpec and parses the provider's response stream.

I don't think Codex or Claude Code should become more branches inside build_request(). That would force local agent runtimes to pretend they are HTTP APIs, which they aren't. I also wouldn't put the integration logic in the TypeScript provider descriptors.

I think dispatch needs to move one level higher:

AgentRunner
  -> AiProviderRegistry
      -> HttpProviderRuntime
      -> CodexAppServerRuntime
      -> ClaudeCodeRuntime

Something roughly like this would keep the runner independent of the transport:

#[async_trait]
trait ProviderRuntime: Send + Sync {
    async fn list_models(
        &self,
        config: &ProviderConfig,
    ) -> Result<Vec<ModelInfo>, AppError>;

    async fn auth_status(
        &self,
        config: &ProviderConfig,
    ) -> Result<ProviderAuthStatus, AppError>;

    async fn stream_chat(
        &self,
        request: ChatRequest,
        events: mpsc::Sender<ChatStreamEventPayload>,
        cancel: CancellationToken,
    ) -> Result<(), AppError>;
}

The existing OpenAI, Anthropic, Google, Ollama, OpenRouter, and custom implementations could sit behind HttpProviderRuntime. Their request construction and stream parsers would not need to change immediately.

The new code could live somewhere like:

src-tauri/src/ai/
  runtime.rs
  http.rs
  codex/
    process.rs
    protocol.rs
  claude/
    process.rs
    protocol.rs

AiProviderRegistry would be Tauri-managed state registered in lib.rs, like the existing runner and runtime state. AgentRunner and model discovery would receive that registry instead of calling the HTTP implementation directly.

For Codex, the Rust adapter could start and manage codex app-server with tokio::process::Command. App-server would continue to own authentication, configuration, models, threads, turns, and cancellation. Asyar would translate its events into the existing ChatStreamEventPayload type. It would never need to read or persist the underlying credentials. The supported protocol already includes account status, model listing, starting threads and turns, and interrupting a turn: Codex app-server documentation.

Claude has two possible implementations:

1. Spawn the authenticated claude runtime directly from Rust and consume its stream JSON output.
2. Generalize the Bun sidecar Asyar already uses with @anthropic-ai/claude-agent-sdk.

There is already useful process-management code in ext_builder/process.rs, and the runtime manager already knows how to acquire Claude. However, the current extension-builder sidecar is feature-specific and requires ANTHROPIC_API_KEY. I would keep the general provider abstraction in Rust even if the Claude implementation eventually delegates protocol work to a Bun sidecar.

Most of this change belongs in Rust. The TypeScript side should only add the provider descriptors and render settings such as:

• Runtime executable or automatic discovery
• Installed and authenticated status
• A test-runtime action
• No API-key input for runtime-backed providers

ProviderConfig currently assumes providers have fields such as api_key and base_url. A tagged transport configuration would describe the difference more accurately:

enum ProviderTransport {
    DirectHttp { /* existing settings */ },
    CodexAppServer { binary_path: Option<PathBuf> },
    ClaudeCode { binary_path: Option<PathBuf> },
}

One behavior also needs an explicit decision: who owns the agent loop and tools? Asyar already has its own tools, persistence, streaming, and cancellation. The first runtime adapter probably should not let both Asyar and Codex or Claude independently run competing tool loops. I would start with Asyar owning that behavior and treat the external runtime as the authenticated model transport.

For a first implementation, Codex app-server still seems like the narrower test. It would establish the provider-runtime interface without changing any existing HTTP provider. Claude could then use the same interface once the maintainers choose between direct CLI streaming and the existing Agent SDK sidecar.

[Xoshbin]

Thanks for opening this discussion and for the thoughtful breakdown, @seanpianka!

I completely agree with you. This is actually an issue I’ve personally experienced and wanted to solve for a long time. With more developers using authenticated local CLIs these days (Codex, Claude Code, Antigravity/agy), avoiding duplicate API billing and separate keys has become an obvious need across the industry.

Your architectural breakdown is spot on:

1. ProviderRuntime trait in Rust: Lifting dispatch from our current HTTP seam to a pluggable runtime trait fits Asyar’s Rust-first design cleanly without touching or breaking existing HTTP providers.
2. Tool loop ownership: Asyar will retain full ownership of the agent loop, tools, permissions, and cancellation—treating the local CLI runtime strictly as the model transport.
3. Phasing: Starting with Codex app-server (and similar headless CLI streaming interfaces) is definitely the right first step.

I'm actively working on introducing this abstraction and adding local CLI runtime support to Asyar. If you have any specific thoughts on the process/RPC details or want to help test early builds, your input is more than welcome!

[seanpianka]

Thanks, I’d be happy to test early builds on Apple Silicon.

One qualification to my earlier wording after looking deeper into T3 Code: treating the CLI "strictly as the model transport" should not mean flattening it into a raw completion API.

T3 does not read OAuth credentials or call subscription endpoints directly. It launches the official runtime, preserves its native session semantics, and translates native events into T3’s provider events. Codex still owns its internal thread and turn lifecycle. Claude still runs through the official Agent SDK. T3 owns the surrounding product behavior, permissions UI, persistence, and cancellation.

A few implementation details from T3 seem worth carrying over:

• Perform the full Codex initialize and initialized handshake with an honest clientInfo identifying Asyar. OpenAI specifically uses this identity for compliance logging. Stay on the stable app-server surface unless an experimental feature is actually needed. Official app-server documentation
• Let account/read and the other official account endpoints report authentication, plan, and rate-limit state. The runtime should own OAuth storage and token refresh. T3’s readiness probe starts app-server, completes the handshake, checks the account, and lists models instead of assuming that finding the executable means it works. T3 Codex probe
• Generate protocol types from Codex’s published schema and pin the upstream version used to generate them. T3 also tolerates unknown notifications and contains compatibility handling for additive protocol changes. A new notification should not take down the entire provider connection. T3 protocol generator
• Inherit the user’s normal process environment. For Claude on macOS, do not override HOME: that changes the keychain lookup and can make an authenticated installation appear signed out. T3 uses CLAUDE_CONFIG_DIR when it needs profile isolation while leaving HOME intact. T3 Claude environment handling
• Treat server requests, approvals, process termination, and cancellation as protocol operations. T3 tracks pending requests and resolves or fails them when the runtime exits instead of leaving a turn hung indefinitely.

The tool-loop boundary is the part I would validate first. Codex app-server and Claude Agent SDK are agent runtimes, not subscription-authenticated equivalents of the raw model APIs. For the first quick-question, translation, or selected-text implementation, disabling or declining runtime tools may be enough. If Asyar later wants its own tools available, it could expose them through supported dynamic tools or MCP while keeping Asyar as the permission and policy boundary.

Trying to run a separate Asyar agent loop around an already agentic runtime is where I would expect the design to get weird.

Anthropic currently says Agent SDK, claude -p, and third-party application usage can draw from the user’s subscription limits, so using their supported SDK/runtime remains the important policy boundary. Anthropic’s current subscription guidance

For testing, I can cover runtime discovery, existing-login reuse, restart behavior, streaming, cancellation, missing or outdated binaries, subscription-limit errors, and the silent selected-text flow.

[Xoshbin]

Hey @seanpianka,

Thank you so much for the detailed insights, the architectural breakdown, and the pointer to T3 Code. That was super helpful and saved me from going down the wrong rabbit hole with temporary prompt-injection shims.

I decided to skip the interim hacks entirely and implemented the native protocol standard directly:

Native Asyar MCP Server (asyar mcp-server): Asyar’s binary now runs a headless JSON-RPC 2.0 MCP stdio server on demand. It natively exposes our core tool registry (calculator, clipboard-read, clipboard-write, fs-read, fs-write, shell-exec, web-fetch) with standard JSON schemas.
Auto-Configuration: Asyar automatically registers itself as an MCP stdio server in:
~/.gemini/config/mcp_config.json (for Google Antigravity / agy)
~/.codex/config.toml under [mcp_servers.asyar] (for Codex) while preserving any existing user configurations or third-party servers.
Native Codex Protocol Client: I built a native Rust client that talks bidirectional JSON-RPC 2.0 to codex app-server --stdio:
Runs full handshake lifecycle (initialize $\to$ initialized).
Queries live account status (account/read) and rate limits (account/rateLimits/read).
Dynamically discovers enabled models (model/list).
Streams assistant turns and reasoning deltas natively.
Settings UI: The AI Settings tab now renders the authenticated account email, plan tier badge, and quota usage.
Testing Status & Request for Feedback
Google Antigravity (agy): Tested end-to-end; agy discovers the Asyar MCP server and executes tool calls seamlessly.
OpenAI Codex: The app-server handshake, MCP config injection, and account/quota introspection have been tested and verified against the local binary. However, I don't have an active paid Codex subscription (nor a Claude subscription), so I haven't been able to run full interactive turn streams against OpenAI's production quota.
The implementation is ready on the branch: 👉 feat/ai-cli

If you (or anyone else following along) have an active Codex account, I’d love it if you could test out the branch and share your experience or any edge cases you run into!

Thanks again for steering us in the right architectural direction!