Anthropic Claude Code, Google Gemini, and OpenAI Codex. The three major AI coding tool providers have all expanded across CLI, web apps, desktop apps, and IDE extensions.

If you are designing a multi-platform product yourself, these three companies offer the best reference architectures available. They each take a fundamentally different approach to solving the same problem: delivering one core logic across multiple surfaces.

This post compares their multi-platform strategies and distills patterns you can apply to your own product.

Platform Coverage at a Glance

First, here is where each company has shipped:

All three cover the essential surfaces (CLI, web, IDE extensions), but how they got there differs significantly.

OpenAI Codex: Unification Through the App Server Protocol

OpenAI solved multi-platform delivery with the Codex App Server, a bidirectional JSON-RPC protocol that decouples the agent core from every client surface.

How It Evolved

Codex started as a TUI (terminal user interface). When the team built the VS Code extension, they needed a way to drive the same agent loop from an IDE UI without reimplementing it.

They first experimented with exposing Codex as an MCP (Model Context Protocol) server, but maintaining MCP semantics in a way that made sense for VS Code proved difficult. IDEs require rich interaction patterns beyond request/response: workspace exploration, streaming progress during agent reasoning, and diff output.

Instead, they introduced a JSON-RPC protocol that mirrored the TUI loop. This became the first version of the App Server.

Codex Architecture Overview

graph TB
    subgraph "First-party products"
        A["Codex Desktop App"]
        B["Codex TUI / CLI"]
        C["Codex Web Runtime"]
    end

    subgraph "Third-party integrations"
        D["JetBrains IDEs"]
        E["VS Code (Codex)"]
        F["Xcode"]
    end

    G["Codex Harness<br/>(via App Server)"]

    A -- "JSON-RPC<br/>over stdio" --> G
    B -- "JSON-RPC<br/>over stdio" --> G
    C -- "HTTP + SSE" --> G
    D -- "JSON-RPC<br/>over stdio" --> G
    E -- "JSON-RPC<br/>over stdio" --> G
    F -- "JSON-RPC<br/>over stdio" --> G

Every client surface talks to the same Codex harness (agent loop and core logic) through the App Server. The transport is JSON-RPC over stdio (JSONL).

Three Conversation Primitives

The App Server protocol is built on three core primitives:

graph TB
    subgraph Thread["Thread"]
        direction TB
        T1["Durable session container"]
        subgraph Turn1["Turn"]
            direction LR
            I1["Item<br/>item/started"]
            I2["Item<br/>item/*/delta"]
            I3["Item<br/>item/completed"]
            I1 --> I2 --> I3
        end
        subgraph Turn2["Turn"]
            direction LR
            I4["Item"] --> I5["Item"] --> I6["Item"]
        end
        Turn1 --> Turn2
    end

1. Item: The atomic unit, typed as user messages, agent messages, tool executions, approval requests, or diffs. Each follows a lifecycle: item/started → item/*/delta → item/completed
2. Turn: One unit of agent work initiated by user input. Starts when the client submits input and ends when the agent finishes producing outputs for that input
3. Thread: A durable container for an ongoing Codex session between a user and an agent. Threads can be created, resumed, forked, and archived

Server-Initiated Requests

A distinctive design in the App Server is the server-to-client request. When the agent needs user approval before executing a command, the server sends a request and pauses the turn until the client responds with “allow” or “deny.”

// Server → Client: approval request
{
  "method": "item/commandExecution/requestApproval",
  "id": 42,
  "params": {
    "reason": "run tests"
  }
}
 
// Client → Server: approval response
{
  "id": 42,
  "result": {
    "decision": "allow"
  }
}

This bidirectionality lets each client implement the approval flow in its own UI paradigm: a dialog in VS Code, an inline prompt in the CLI, a modal on the web.

Three Deployment Patterns

Partner integrations (JetBrains, Xcode) can keep the client stable while pointing to a newer App Server binary, decoupling release cycles. The App Server’s JSON-RPC interface is designed for backward compatibility, so older clients can safely talk to newer servers.

Takeaways from the Codex Approach

• Protocol-first: Expose core logic through a well-defined protocol, making each client a protocol consumer. A stable protocol lets you decouple client release cycles
• Why MCP was not enough: The streaming diffs, approval flows, and thread persistence that IDEs need did not map cleanly onto MCP’s tool-oriented model. Design the protocol around your product’s interaction patterns
• Backward compatibility by design: Partner integrations cannot ship frequent client updates, so server-side improvements must deploy without requiring client releases

Claude Code: Turning the Harness Into a Library

Anthropic solved multi-platform delivery with the Claude Agent SDK, which packages the Claude Code engine as a callable library.

How It Evolved

Claude Code started as a CLI, and its core engine (agent loop, tool execution, permission management, context management) was factored out as the “agent harness.” This harness was then published as the Claude Agent SDK in both Python and TypeScript, so the CLI, desktop app, web, and IDE extensions all share the same underlying engine.

Claude Code Architecture Overview

graph TB
    SDK["Claude Agent SDK<br/>(Agent loop / Tools / Permissions)"]

    SDK --> CLI["CLI"]
    SDK --> Desktop["Desktop App"]
    SDK --> Web["Web"]
    SDK --> IDE["IDE extensions<br/>(VS Code, JetBrains)"]

    Config["~/.claude/<br/>Shared settings, CLAUDE.md, MCP"]
    Config -. "Shared across all platforms" .-> CLI
    Config -. "Shared across all platforms" .-> Desktop
    Config -. "Shared across all platforms" .-> Web
    Config -. "Shared across all platforms" .-> IDE

Harness Components

The Claude Code harness consists of several key subsystems:

Permission pipeline: A deny-first rule evaluation system that controls every tool call. The model decides what it wants to do; a separate system decides whether it is allowed. In auto mode, a background classifier on a separate model instance evaluates safety.

Tool dispatch: Roughly 19-40 permission-gated tools including Read, Edit, Bash, Grep, and WebSearch. Each tool is independently sandboxed with granular, per-tool access control rather than blanket filesystem access.

Context management: When token usage approaches 98% of the context window, the harness automatically summarizes earlier history. MCP tool output is capped at 25,000 tokens, with excess persisted to disk.

Session management: Sessions store the full history of messages, tool uses, and results locally. The system takes file snapshots before changes, enabling rollback.

Publishing as an SDK

The Claude Agent SDK exposes this harness as a library:

from claude_agent_sdk import query, ClaudeAgentOptions
 
async for message in query(
    prompt="Find and fix the bug in auth.py",
    options=ClaudeAgentOptions(
        allowed_tools=["Read", "Edit", "Bash"],
        permission_mode="acceptEdits",
    ),
):
    print(message)

The SDK includes built-in tool execution, so consumers do not need to implement tool handling themselves. File reading, command execution, and code search work out of the box.

Cross-Platform Unification

All platforms share ~/.claude/ for user-level settings. CLAUDE.md files, MCP server configuration, and auto memory work across every surface. Version 1.8.0 tightened cross-platform behavior parity so the same rules, agents, and skills work uniformly across all four platforms.

Session portability is another key feature. You can hand off a CLI session to the desktop app with /desktop, pull a web session into your terminal with claude --teleport, or start a long-running task on the web and check it from your phone.

Takeaways from the Claude Code Approach

• Library-first: Expose core logic as a library (SDK) rather than a protocol. Consumers drive the agent through function calls rather than building protocol clients
• Shared configuration: A user-level settings directory (~/.claude/) shared across all platforms ensures configuration consistency
• Session portability: Letting users move sessions between platforms greatly improves workflow flexibility

Google Gemini: Three Products Along an Autonomy Spectrum

Google takes a fundamentally different approach. Rather than shipping one core engine to multiple clients, they offer three separate products optimized for different levels of autonomy.

The Three Products

Gemini Code Assist: An IDE extension for VS Code, JetBrains, and Android Studio. The developer drives; AI is the copilot.

Gemini CLI: An open-source CLI tool under the Apache 2.0 license. Built for terminal-native developers who want automation and scriptable workflows.

Antigravity: An agent-first IDE (a VS Code fork) with three surfaces: an editor, a manager for autonomous agent orchestration, and browser integration for automated testing.

The Autonomy Spectrum

graph LR
    subgraph "Low autonomy"
        A["Gemini Code Assist<br/>(IDE extension)<br/>AI = copilot"]
    end
    subgraph "Medium autonomy"
        B["Gemini CLI<br/>(Terminal)<br/>AI = utility tool"]
    end
    subgraph "High autonomy"
        C["Antigravity<br/>(Agent-first IDE)<br/>AI = autonomous developer"]
    end

    A --> B --> C

Google’s strategy is not about delivering one product everywhere, but about providing purpose-built products optimized for each platform and autonomy level.

IDE Integration Approach

Gemini CLI’s IDE integration uses the ACP (Agent Client Protocol), an open standard. Instead of building separate integrations per IDE, the standardized protocol connects to JetBrains, Zed, and other compliant editors through a shared agent registry.

For VS Code, a dedicated companion extension provides workspace awareness (the 10 most recently accessed files, active cursor position, selected text) and native diff rendering.

Multi-Tier Backend

Another Google characteristic is that different authentication methods connect to different service tiers:

The same CLI tool connects to a different service with different terms of service depending on the authentication method.

Takeaways from Google’s Approach

• Product separation: When autonomy levels diverge significantly, separate products may serve users better than a single product stretched across use cases
• Open protocol adoption: Using an open standard like ACP reduces IDE integration costs while encouraging ecosystem growth
• Authentication-based service tiering: Routing the same client to different service tiers based on authentication is effective for serving individual users through enterprise customers

Comparing the Three Design Patterns

graph TB
    subgraph Claude["Claude Code: Library-first"]
        direction TB
        CL_Core["Agent Harness"]
        CL_SDK["Agent SDK<br/>Python / TypeScript"]
        CL_Clients["CLI / Desktop / Web / IDE"]
        CL_Core --> CL_SDK --> CL_Clients
    end

    subgraph Codex["Codex: Protocol-first"]
        direction TB
        C_Core["Codex Core (Rust)"]
        C_Proto["App Server<br/>JSON-RPC protocol"]
        C_Clients["CLI / Desktop / Web / IDE"]
        C_Core --> C_Proto --> C_Clients
    end

    subgraph Google["Gemini: Product separation"]
        direction TB
        G_API["Gemini API / Vertex AI"]
        G_P1["Code Assist"]
        G_P2["Gemini CLI"]
        G_P3["Antigravity"]
        G_API --> G_P1
        G_API --> G_P2
        G_API --> G_P3
    end

Applying These Patterns to Your Own Product

Here is how to think about these approaches for your own multi-platform design.

Pattern 1: Protocol-First (Codex Style)

Expose core logic through a custom bidirectional protocol. Each platform becomes a protocol client.

Best for:

• Broad third-party integration is a key requirement
• Client and server release cycles need to be decoupled
• Rich interactions (streaming, approval flows) are essential

Tradeoffs:

• Each client needs to build JSON-RPC bindings
• Maintaining backward compatibility in the protocol is an ongoing cost

Pattern 2: Library-First (Claude Code Style)

Expose core logic as an SDK (library). Each platform embeds the SDK.

Best for:

• First-party platform expansion is the primary goal
• Low barrier to integration is important (function calls vs. protocol implementation)
• Built-in tool execution is part of the value proposition

Tradeoffs:

• SDK language support constrains which platforms can integrate
• Each client must track SDK updates

Pattern 3: Product Separation (Google Style)

Offer independent products for each platform or autonomy level.

Best for:

• Usage patterns differ dramatically across platforms
• Delivering a fully optimized experience per platform is the priority
• The team is large enough to develop multiple products in parallel

Tradeoffs:

• Maintaining feature parity across products is difficult
• Brand coherence becomes more complex to manage

Which Pattern to Choose

For most startups, Pattern 2 (library-first) is the most practical starting point. Build the CLI as the core, factor the core logic into an SDK, then expand to web and IDE extensions that embed the SDK.

Pattern 1 (protocol-first) becomes worth considering once third-party IDE and tool integrations emerge as a major requirement. Just as OpenAI started with a CLI and designed the App Server when VS Code integration demanded it, the need for a formal protocol naturally arises as use cases expand.

Pattern 3 (product separation) is suited for organizations with the resources to staff dedicated teams for each platform, like Google.

Conclusion

OpenAI Codex, Claude Code, and Google Gemini have each taken a different path to multi-platform delivery:

• OpenAI Codex: Unified through the App Server, a bidirectional JSON-RPC protocol. Evaluated MCP, chose a custom protocol, and designed for third-party release cycle decoupling from the start
• Claude Code: Unified through the Agent SDK, a library that exposes the harness. All platforms share the same SDK, with shared configuration and session portability for a seamless experience
• Google Gemini: Three separate products (Code Assist, Gemini CLI, Antigravity) covering an autonomy spectrum, using the open ACP protocol for IDE integration

What they all share is that none of them built for every platform at once from day one. Codex started as a CLI. Claude Code started as a CLI. They established the core first, then expanded to other surfaces. For resource-constrained teams, this sequencing may be the most important lesson of all.

References

• Unlocking the Codex harness: how we built the App Server (OpenAI, February 4, 2026)
• Harness engineering: leveraging Codex in an agent-first world (OpenAI, February 11, 2026)
• Codex App Server documentation
• Claude Code overview
• Claude Agent SDK overview
• Gemini CLI GitHub repository
• Gemini Code Assist overview
• Gemini CLI: IDE Integration