Phase 5: Configuration & Documentation

Updated all documentation and configuration files: Documentation changes: - Updated README.md to describe LLMX as LiteLLM-powered fork - Updated CLAUDE.md with LiteLLM integration details - Updated 50+ markdown files across docs/, llmx-rs/, llmx-cli/, sdk/ - Changed all references: codex → llmx, Codex → LLMX - Updated package references: @openai/codex → @llmx/llmx - Updated repository URLs: github.com/openai/codex → github.com/valknar/llmx Configuration changes: - Updated .github/dependabot.yaml - Updated .github workflow files - Updated cliff.toml (changelog configuration) - Updated Cargo.toml comments Key branding updates: - Project description: "coding agent from OpenAI" → "coding agent powered by LiteLLM" - Added attribution to original OpenAI Codex project - Documented LiteLLM integration benefits Files changed: 51 files (559 insertions, 559 deletions) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-11 14:45:40 +01:00
parent 0c2c36e14e
commit c493ea1347
51 changed files with 559 additions and 559 deletions
--- a/llmx-rs/Cargo.toml
+++ b/llmx-rs/Cargo.toml
@@ -267,7 +267,7 @@ lto = "fat"
 # remove everything to make the binary as small as possible.
 strip = "symbols"

-# See https://github.com/openai/codex/issues/1411 for details.
+# See https://github.com/openai/llmx/issues/1411 for details.
 codegen-units = 1

 [profile.ci-test]
--- a/llmx-rs/README.md
+++ b/llmx-rs/README.md
@@ -1,74 +1,74 @@
-# Codex CLI (Rust Implementation)
+# LLMX CLI (Rust Implementation)

-We provide Codex CLI as a standalone, native executable to ensure a zero-dependency install.
+We provide LLMX CLI as a standalone, native executable to ensure a zero-dependency install.

-## Installing Codex
+## Installing LLMX

-Today, the easiest way to install Codex is via `npm`:
+Today, the easiest way to install LLMX is via `npm`:

 ```shell
-npm i -g @openai/codex
-codex
+npm i -g @llmx/llmx
+llmx
 ```

-You can also install via Homebrew (`brew install --cask codex`) or download a platform-specific release directly from our [GitHub Releases](https://github.com/openai/codex/releases).
+You can also install via Homebrew (`brew install --cask llmx`) or download a platform-specific release directly from our [GitHub Releases](https://github.com/valknar/llmx/releases).

 ## Documentation quickstart

- First run with Codex? Follow the walkthrough in [`docs/getting-started.md`](../docs/getting-started.md) for prompts, keyboard shortcuts, and session management.
- Already shipping with Codex and want deeper control? Jump to [`docs/advanced.md`](../docs/advanced.md) and the configuration reference at [`docs/config.md`](../docs/config.md).
+- First run with LLMX? Follow the walkthrough in [`docs/getting-started.md`](../docs/getting-started.md) for prompts, keyboard shortcuts, and session management.
+- Already shipping with LLMX and want deeper control? Jump to [`docs/advanced.md`](../docs/advanced.md) and the configuration reference at [`docs/config.md`](../docs/config.md).

 ## What's new in the Rust CLI

-The Rust implementation is now the maintained Codex CLI and serves as the default experience. It includes a number of features that the legacy TypeScript CLI never supported.
+The Rust implementation is now the maintained LLMX CLI and serves as the default experience. It includes a number of features that the legacy TypeScript CLI never supported.

 ### Config

-Codex supports a rich set of configuration options. Note that the Rust CLI uses `config.toml` instead of `config.json`. See [`docs/config.md`](../docs/config.md) for details.
+LLMX supports a rich set of configuration options. Note that the Rust CLI uses `config.toml` instead of `config.json`. See [`docs/config.md`](../docs/config.md) for details.

 ### Model Context Protocol Support

 #### MCP client

-Codex CLI functions as an MCP client that allows the Codex CLI and IDE extension to connect to MCP servers on startup. See the [`configuration documentation`](../docs/config.md#mcp_servers) for details.
+LLMX CLI functions as an MCP client that allows the LLMX CLI and IDE extension to connect to MCP servers on startup. See the [`configuration documentation`](../docs/config.md#mcp_servers) for details.

 #### MCP server (experimental)

-Codex can be launched as an MCP _server_ by running `codex mcp-server`. This allows _other_ MCP clients to use Codex as a tool for another agent.
+LLMX can be launched as an MCP _server_ by running `llmx mcp-server`. This allows _other_ MCP clients to use LLMX as a tool for another agent.

 Use the [`@modelcontextprotocol/inspector`](https://github.com/modelcontextprotocol/inspector) to try it out:

 ```shell
-npx @modelcontextprotocol/inspector codex mcp-server
+npx @modelcontextprotocol/inspector llmx mcp-server
 ```

-Use `codex mcp` to add/list/get/remove MCP server launchers defined in `config.toml`, and `codex mcp-server` to run the MCP server directly.
+Use `llmx mcp` to add/list/get/remove MCP server launchers defined in `config.toml`, and `llmx mcp-server` to run the MCP server directly.

 ### Notifications

 You can enable notifications by configuring a script that is run whenever the agent finishes a turn. The [notify documentation](../docs/config.md#notify) includes a detailed example that explains how to get desktop notifications via [terminal-notifier](https://github.com/julienXX/terminal-notifier) on macOS.

-### `codex exec` to run Codex programmatically/non-interactively
+### `llmx exec` to run LLMX programmatically/non-interactively

-To run Codex non-interactively, run `codex exec PROMPT` (you can also pass the prompt via `stdin`) and Codex will work on your task until it decides that it is done and exits. Output is printed to the terminal directly. You can set the `RUST_LOG` environment variable to see more about what's going on.
+To run LLMX non-interactively, run `llmx exec PROMPT` (you can also pass the prompt via `stdin`) and LLMX will work on your task until it decides that it is done and exits. Output is printed to the terminal directly. You can set the `RUST_LOG` environment variable to see more about what's going on.

-### Experimenting with the Codex Sandbox
+### Experimenting with the LLMX Sandbox

-To test to see what happens when a command is run under the sandbox provided by Codex, we provide the following subcommands in Codex CLI:
+To test to see what happens when a command is run under the sandbox provided by LLMX, we provide the following subcommands in LLMX CLI:

 ```
 # macOS
-codex sandbox macos [--full-auto] [--log-denials] [COMMAND]...
+llmx sandbox macos [--full-auto] [--log-denials] [COMMAND]...

 # Linux
-codex sandbox linux [--full-auto] [COMMAND]...
+llmx sandbox linux [--full-auto] [COMMAND]...

 # Windows
-codex sandbox windows [--full-auto] [COMMAND]...
+llmx sandbox windows [--full-auto] [COMMAND]...

 # Legacy aliases
-codex debug seatbelt [--full-auto] [--log-denials] [COMMAND]...
-codex debug landlock [--full-auto] [COMMAND]...
+llmx debug seatbelt [--full-auto] [--log-denials] [COMMAND]...
+llmx debug landlock [--full-auto] [COMMAND]...
 ```

 ### Selecting a sandbox policy via `--sandbox`
@@ -76,23 +76,23 @@ codex debug landlock [--full-auto] [COMMAND]...
 The Rust CLI exposes a dedicated `--sandbox` (`-s`) flag that lets you pick the sandbox policy **without** having to reach for the generic `-c/--config` option:

 ```shell
-# Run Codex with the default, read-only sandbox
-codex --sandbox read-only
+# Run LLMX with the default, read-only sandbox
+llmx --sandbox read-only

 # Allow the agent to write within the current workspace while still blocking network access
-codex --sandbox workspace-write
+llmx --sandbox workspace-write

 # Danger! Disable sandboxing entirely (only do this if you are already running in a container or other isolated env)
-codex --sandbox danger-full-access
+llmx --sandbox danger-full-access
 ```

-The same setting can be persisted in `~/.codex/config.toml` via the top-level `sandbox_mode = "MODE"` key, e.g. `sandbox_mode = "workspace-write"`.
+The same setting can be persisted in `~/.llmx/config.toml` via the top-level `sandbox_mode = "MODE"` key, e.g. `sandbox_mode = "workspace-write"`.

 ## Code Organization

 This folder is the root of a Cargo workspace. It contains quite a bit of experimental code, but here are the key crates:

- [`core/`](./core) contains the business logic for Codex. Ultimately, we hope this to be a library crate that is generally useful for building other Rust/native applications that use Codex.
+- [`core/`](./core) contains the business logic for LLMX. Ultimately, we hope this to be a library crate that is generally useful for building other Rust/native applications that use LLMX.
 - [`exec/`](./exec) "headless" CLI for use in automation.
 - [`tui/`](./tui) CLI that launches a fullscreen TUI built with [Ratatui](https://ratatui.rs/).
 - [`cli/`](./cli) CLI multitool that provides the aforementioned CLIs via subcommands.
--- a/llmx-rs/ansi-escape/README.md
+++ b/llmx-rs/ansi-escape/README.md
@@ -1,4 +1,4 @@
-# oai-codex-ansi-escape
+# oai-llmx-ansi-escape

 Small helper functions that wrap functionality from
 <https://crates.io/crates/ansi-to-tui>:
--- a/llmx-rs/app-server/README.md
+++ b/llmx-rs/app-server/README.md
@@ -1,18 +1,18 @@
-# codex-app-server
+# llmx-app-server

-`codex app-server` is the interface Codex uses to power rich interfaces such as the [Codex VS Code extension](https://marketplace.visualstudio.com/items?itemName=openai.chatgpt). The message schema is currently unstable, but those who wish to build experimental UIs on top of Codex may find it valuable.
+`llmx app-server` is the interface LLMX uses to power rich interfaces such as the [LLMX VS Code extension](https://marketplace.visualstudio.com/items?itemName=openai.chatgpt). The message schema is currently unstable, but those who wish to build experimental UIs on top of LLMX may find it valuable.

 ## Protocol

-Similar to [MCP](https://modelcontextprotocol.io/), `codex app-server` supports bidirectional communication, streaming JSONL over stdio. The protocol is JSON-RPC 2.0, though the `"jsonrpc":"2.0"` header is omitted.
+Similar to [MCP](https://modelcontextprotocol.io/), `llmx app-server` supports bidirectional communication, streaming JSONL over stdio. The protocol is JSON-RPC 2.0, though the `"jsonrpc":"2.0"` header is omitted.

 ## Message Schema

-Currently, you can dump a TypeScript version of the schema using `codex app-server generate-ts`, or a JSON Schema bundle via `codex app-server generate-json-schema`. Each output is specific to the version of Codex you used to run the command, so the generated artifacts are guaranteed to match that version.
+Currently, you can dump a TypeScript version of the schema using `llmx app-server generate-ts`, or a JSON Schema bundle via `llmx app-server generate-json-schema`. Each output is specific to the version of LLMX you used to run the command, so the generated artifacts are guaranteed to match that version.

 ```
-codex app-server generate-ts --out DIR
-codex app-server generate-json-schema --out DIR
+llmx app-server generate-ts --out DIR
+llmx app-server generate-json-schema --out DIR
 ```

 ## Initialization
@@ -23,40 +23,40 @@ Example:

 ```json
 { "method": "initialize", "id": 0, "params": {
-    "clientInfo": { "name": "codex-vscode", "title": "Codex VS Code Extension", "version": "0.1.0" }
+    "clientInfo": { "name": "llmx-vscode", "title": "LLMX VS Code Extension", "version": "0.1.0" }
 } }
-{ "id": 0, "result": { "userAgent": "codex-app-server/0.1.0 codex-vscode/0.1.0" } }
+{ "id": 0, "result": { "userAgent": "llmx-app-server/0.1.0 llmx-vscode/0.1.0" } }
 { "method": "initialized" }
 ```

 ## Core primitives

 We have 3 top level primitives:
- Thread - a conversation between the Codex agent and a user. Each thread contains multiple turns.
+- Thread - a conversation between the LLMX agent and a user. Each thread contains multiple turns.
 - Turn - one turn of the conversation, typically starting with a user message and finishing with an agent message. Each turn contains multiple items.
 - Item - represents user inputs and agent outputs as part of the turn, persisted and used as the context for future conversations.

 ## Thread & turn endpoints

-The JSON-RPC API exposes dedicated methods for managing Codex conversations. Threads store long-lived conversation metadata, and turns store the per-message exchange (input → Codex output, including streamed items). Use the thread APIs to create, list, or archive sessions, then drive the conversation with turn APIs and notifications.
+The JSON-RPC API exposes dedicated methods for managing LLMX conversations. Threads store long-lived conversation metadata, and turns store the per-message exchange (input → LLMX output, including streamed items). Use the thread APIs to create, list, or archive sessions, then drive the conversation with turn APIs and notifications.

 ### Quick reference
 - `thread/start` — create a new thread; emits `thread/started` and auto-subscribes you to turn/item events for that thread.
 - `thread/resume` — reopen an existing thread by id so subsequent `turn/start` calls append to it.
 - `thread/list` — page through stored rollouts; supports cursor-based pagination and optional `modelProviders` filtering.
 - `thread/archive` — move a thread’s rollout file into the archived directory; returns `{}` on success.
- `turn/start` — add user input to a thread and begin Codex generation; responds with the initial `turn` object and streams `turn/started`, `item/*`, and `turn/completed` notifications.
+- `turn/start` — add user input to a thread and begin LLMX generation; responds with the initial `turn` object and streams `turn/started`, `item/*`, and `turn/completed` notifications.
 - `turn/interrupt` — request cancellation of an in-flight turn by `(thread_id, turn_id)`; success is an empty `{}` response and the turn finishes with `status: "interrupted"`.

 ### 1) Start or resume a thread

-Start a fresh thread when you need a new Codex conversation.
+Start a fresh thread when you need a new LLMX conversation.

 ```json
 { "method": "thread/start", "id": 10, "params": {
    // Optionally set config settings. If not specified, will use the user's
    // current config settings.
-    "model": "gpt-5-codex",
+    "model": "gpt-5-llmx",
    "cwd": "/Users/me/project",
    "approvalPolicy": "never",
    "sandbox": "workspaceWrite",
@@ -117,7 +117,7 @@ An archived thread will not appear in future calls to `thread/list`.

 ### 4) Start a turn (send user input)

-Turns attach user input (text or images) to a thread and trigger Codex generation. The `input` field is a list of discriminated unions:
+Turns attach user input (text or images) to a thread and trigger LLMX generation. The `input` field is a list of discriminated unions:

 - `{"type":"text","text":"Explain this diff"}`
 - `{"type":"image","url":"https://…png"}`
@@ -137,7 +137,7 @@ You can optionally specify config overrides on the new turn. If specified, these
        "writableRoots": ["/Users/me/project"],
        "networkAccess": true
    },
-    "model": "gpt-5-codex",
+    "model": "gpt-5-llmx",
    "effort": "medium",
    "summary": "concise"
 } }
@@ -161,7 +161,7 @@ You can cancel a running Turn with `turn/interrupt`.
 { "id": 31, "result": {} }
 ```

-The server requests cancellations for running subprocesses, then emits a `turn/completed` event with `status: "interrupted"`. Rely on the `turn/completed` to know when Codex-side cleanup is done.
+The server requests cancellations for running subprocesses, then emits a `turn/completed` event with `status: "interrupted"`. Rely on the `turn/completed` to know when LLMX-side cleanup is done.

 ## Auth endpoints

@@ -193,7 +193,7 @@ Response examples:

 Field notes:
 - `refreshToken` (bool): set `true` to force a token refresh.
- `requiresOpenaiAuth` reflects the active provider; when `false`, Codex can run without OpenAI credentials.
+- `requiresOpenaiAuth` reflects the active provider; when `false`, LLMX can run without OpenAI credentials.

 ### 2) Log in with an API key

@@ -255,6 +255,6 @@ Field notes:

 ### Dev notes

- `codex app-server generate-ts --out <dir>` emits v2 types under `v2/`.
- `codex app-server generate-json-schema --out <dir>` outputs `codex_app_server_protocol.schemas.json`.
+- `llmx app-server generate-ts --out <dir>` emits v2 types under `v2/`.
+- `llmx app-server generate-json-schema --out <dir>` outputs `codex_app_server_protocol.schemas.json`.
 - See [“Authentication and authorization” in the config docs](../../docs/config.md#authentication-and-authorization) for configuration knobs.
--- a/llmx-rs/chatgpt/README.md
+++ b/llmx-rs/chatgpt/README.md
@@ -1,5 +1,5 @@
 # ChatGPT

-This crate pertains to first party ChatGPT APIs and products such as Codex agent.
+This crate pertains to first party ChatGPT APIs and products such as LLMX agent.

 This crate should be primarily built and maintained by OpenAI employees. Please reach out to a maintainer before making an external contribution.
--- a/llmx-rs/common/README.md
+++ b/llmx-rs/common/README.md
@@ -1,4 +1,4 @@
-# codex-common
+# llmx-common

 This crate is designed for utilities that need to be shared across other crates in the workspace, but should not go in `core`.

--- a/llmx-rs/core/README.md
+++ b/llmx-rs/core/README.md
@@ -1,10 +1,10 @@
-# codex-core
+# llmx-core

-This crate implements the business logic for Codex. It is designed to be used by the various Codex UIs written in Rust.
+This crate implements the business logic for LLMX. It is designed to be used by the various LLMX UIs written in Rust.

 ## Dependencies

-Note that `codex-core` makes some assumptions about certain helper utilities being available in the environment. Currently, this support matrix is:
+Note that `llmx-core` makes some assumptions about certain helper utilities being available in the environment. Currently, this support matrix is:

 ### macOS

@@ -12,8 +12,8 @@ Expects `/usr/bin/sandbox-exec` to be present.

 ### Linux

-Expects the binary containing `codex-core` to run the equivalent of `codex sandbox linux` (legacy alias: `codex debug landlock`) when `arg0` is `codex-linux-sandbox`. See the `codex-arg0` crate for details.
+Expects the binary containing `llmx-core` to run the equivalent of `llmx sandbox linux` (legacy alias: `llmx debug landlock`) when `arg0` is `llmx-linux-sandbox`. See the `llmx-arg0` crate for details.

 ### All Platforms

-Expects the binary containing `codex-core` to simulate the virtual `apply_patch` CLI when `arg1` is `--codex-run-as-apply-patch`. See the `codex-arg0` crate for details.
+Expects the binary containing `llmx-core` to simulate the virtual `apply_patch` CLI when `arg1` is `--llmx-run-as-apply-patch`. See the `llmx-arg0` crate for details.
--- a/llmx-rs/core/gpt_5_codex_prompt.md
+++ b/llmx-rs/core/gpt_5_codex_prompt.md
@@ -1,4 +1,4 @@
-You are Codex, based on GPT-5. You are running as a coding agent in the Codex CLI on a user's computer.
+You are LLMX, based on GPT-5. You are running as a coding agent in the LLMX CLI on a user's computer.

 ## General

@@ -27,9 +27,9 @@ When using the planning tool:
 - Do not make single-step plans.
 - When you made a plan, update it after having performed one of the sub-tasks that you shared on the plan.

-## Codex CLI harness, sandboxing, and approvals
+## LLMX CLI harness, sandboxing, and approvals

-The Codex CLI harness supports several different configurations for sandboxing and escalation approvals that the user can choose from.
+The LLMX CLI harness supports several different configurations for sandboxing and escalation approvals that the user can choose from.

 Filesystem sandboxing defines which files can be read or written. The options for `sandbox_mode` are:
 - **read-only**: The sandbox only permits reading files.
--- a/llmx-rs/core/prompt.md
+++ b/llmx-rs/core/prompt.md
@@ -1,4 +1,4 @@
-You are a coding agent running in the Codex CLI, a terminal-based coding assistant. Codex CLI is an open source project led by OpenAI. You are expected to be precise, safe, and helpful.
+You are a coding agent running in the LLMX CLI, a terminal-based coding assistant. LLMX CLI is an open source project led by OpenAI. You are expected to be precise, safe, and helpful.

 Your capabilities:

@@ -6,7 +6,7 @@ Your capabilities:
 - Communicate with the user by streaming thinking & responses, and by making & updating plans.
 - Emit function calls to run terminal commands and apply patches. Depending on how this specific run is configured, you can request that these function calls be escalated to the user for approval before running. More on this in the "Sandbox and approvals" section.

-Within this context, Codex refers to the open-source agentic coding interface (not the old Codex language model built by OpenAI).
+Within this context, LLMX refers to the open-source agentic coding interface (not the old LLMX language model built by OpenAI).

 # How you work

@@ -148,7 +148,7 @@ If completing the user's task requires writing or modifying files, your code and

 ## Sandbox and approvals

-The Codex CLI harness supports several different sandboxing, and approval configurations that the user can choose from.
+The LLMX CLI harness supports several different sandboxing, and approval configurations that the user can choose from.

 Filesystem sandboxing prevents you from editing files without user approval. The options are:

--- a/llmx-rs/docs/codex_mcp_interface.md
+++ b/llmx-rs/docs/codex_mcp_interface.md
@@ -1,19 +1,19 @@
-# Codex MCP Server Interface [experimental]
+# LLMX MCP Server Interface [experimental]

-This document describes Codex’s experimental MCP server interface: a JSON‑RPC API that runs over the Model Context Protocol (MCP) transport to control a local Codex engine.
+This document describes LLMX’s experimental MCP server interface: a JSON‑RPC API that runs over the Model Context Protocol (MCP) transport to control a local LLMX engine.

 - Status: experimental and subject to change without notice
- Server binary: `codex mcp-server` (or `codex-mcp-server`)
+- Server binary: `llmx mcp-server` (or `llmx-mcp-server`)
 - Transport: standard MCP over stdio (JSON‑RPC 2.0, line‑delimited)

 ## Overview

-Codex exposes a small set of MCP‑compatible methods to create and manage conversations, send user input, receive live events, and handle approval prompts. The types are defined in `protocol/src/mcp_protocol.rs` and re‑used by the MCP server implementation in `mcp-server/`.
+LLMX exposes a small set of MCP‑compatible methods to create and manage conversations, send user input, receive live events, and handle approval prompts. The types are defined in `protocol/src/mcp_protocol.rs` and re‑used by the MCP server implementation in `mcp-server/`.

 At a glance:

 - Conversations
-  - `newConversation` → start a Codex session
+  - `newConversation` → start a LLMX session
  - `sendUserMessage` / `sendUserTurn` → send user input into a conversation
  - `interruptConversation` → stop the current turn
  - `listConversations`, `resumeConversation`, `archiveConversation`
@@ -29,25 +29,25 @@ At a glance:
  - `applyPatchApproval`, `execCommandApproval`
 - Notifications (server → client)
  - `loginChatGptComplete`, `authStatusChange`
-  - `codex/event` stream with agent events
+  - `llmx/event` stream with agent events

 See code for full type definitions and exact shapes: `protocol/src/mcp_protocol.rs`.

 ## Starting the server

-Run Codex as an MCP server and connect an MCP client:
+Run LLMX as an MCP server and connect an MCP client:

 ```bash
-codex mcp-server | your_mcp_client
+llmx mcp-server | your_mcp_client
 ```

 For a simple inspection UI, you can also try:

 ```bash
-npx @modelcontextprotocol/inspector codex mcp-server
+npx @modelcontextprotocol/inspector llmx mcp-server
 ```

-Use the separate `codex mcp` subcommand to manage configured MCP server launchers in `config.toml`.
+Use the separate `llmx mcp` subcommand to manage configured MCP server launchers in `config.toml`.

 ## Conversations

@@ -55,7 +55,7 @@ Start a new session with optional overrides:

 Request `newConversation` params (subset):

- `model`: string model id (e.g. "o3", "gpt-5", "gpt-5-codex")
+- `model`: string model id (e.g. "o3", "gpt-5", "gpt-5-llmx")
 - `profile`: optional named profile
 - `cwd`: optional working directory
 - `approvalPolicy`: `untrusted` | `on-request` | `on-failure` | `never`
@@ -78,7 +78,7 @@ List/resume/archive: `listConversations`, `resumeConversation`, `archiveConversa

 ## Models

-Fetch the catalog of models available in the current Codex build with `model/list`. The request accepts optional pagination inputs:
+Fetch the catalog of models available in the current LLMX build with `model/list`. The request accepts optional pagination inputs:

 - `pageSize` – number of models to return (defaults to a server-selected value)
 - `cursor` – opaque string from the previous response’s `nextCursor`
@@ -98,14 +98,14 @@ Each response yields:

 While a conversation runs, the server sends notifications:

- `codex/event` with the serialized Codex event payload. The shape matches `core/src/protocol.rs`’s `Event` and `EventMsg` types. Some notifications include a `_meta.requestId` to correlate with the originating request.
+- `llmx/event` with the serialized LLMX event payload. The shape matches `core/src/protocol.rs`’s `Event` and `EventMsg` types. Some notifications include a `_meta.requestId` to correlate with the originating request.
 - Auth notifications via method names `loginChatGptComplete` and `authStatusChange`.

 Clients should render events and, when present, surface approval requests (see next section).

 ## Approvals (server → client)

-When Codex needs approval to apply changes or run commands, the server issues JSON‑RPC requests to the client:
+When LLMX needs approval to apply changes or run commands, the server issues JSON‑RPC requests to the client:

 - `applyPatchApproval { conversationId, callId, fileChanges, reason?, grantRoot? }`
 - `execCommandApproval { conversationId, callId, command, cwd, reason? }`
@@ -131,10 +131,10 @@ Server responds:
 Then send input:

 ```json
-{ "jsonrpc": "2.0", "id": 2, "method": "sendUserMessage", "params": { "conversationId": "c7b0…", "items": [{ "type": "text", "text": "Hello Codex" }] } }
+{ "jsonrpc": "2.0", "id": 2, "method": "sendUserMessage", "params": { "conversationId": "c7b0…", "items": [{ "type": "text", "text": "Hello LLMX" }] } }
 ```

-While processing, the server emits `codex/event` notifications containing agent output, approvals, and status updates.
+While processing, the server emits `llmx/event` notifications containing agent output, approvals, and status updates.

 ## Compatibility and stability

--- a/llmx-rs/docs/protocol_v1.md
+++ b/llmx-rs/docs/protocol_v1.md
@@ -6,22 +6,22 @@ NOTE: The code might not completely match this spec. There are a few minor chang

 ## Entities

-These are entities exit on the codex backend. The intent of this section is to establish vocabulary and construct a shared mental model for the `Codex` core system.
+These are entities exit on the llmx backend. The intent of this section is to establish vocabulary and construct a shared mental model for the `LLMX` core system.

 0. `Model`
   - In our case, this is the Responses REST API
-1. `Codex`
-   - The core engine of codex
+1. `LLMX`
+   - The core engine of llmx
   - Runs locally, either in a background thread or separate process
   - Communicated to via a queue pair – SQ (Submission Queue) / EQ (Event Queue)
   - Takes user input, makes requests to the `Model`, executes commands and applies patches.
 2. `Session`
-   - The `Codex`'s current configuration and state
-   - `Codex` starts with no `Session`, and it is initialized by `Op::ConfigureSession`, which should be the first message sent by the UI.
+   - The `LLMX`'s current configuration and state
+   - `LLMX` starts with no `Session`, and it is initialized by `Op::ConfigureSession`, which should be the first message sent by the UI.
   - The current `Session` can be reconfigured with additional `Op::ConfigureSession` calls.
   - Any running execution is aborted when the session is reconfigured.
 3. `Task`
-   - A `Task` is `Codex` executing work in response to user input.
+   - A `Task` is `LLMX` executing work in response to user input.
   - `Session` has at most one `Task` running at a time.
   - Receiving `Op::UserInput` starts a `Task`
   - Consists of a series of `Turn`s
@@ -35,28 +35,28 @@ These are entities exit on the codex backend. The intent of this section is to e
   - One cycle of iteration in a `Task`, consists of:
     - A request to the `Model` - (initially) prompt + (optional) `last_response_id`, or (in loop) previous turn output
     - The `Model` streams responses back in an SSE, which are collected until "completed" message and the SSE terminates
-     - `Codex` then executes command(s), applies patch(es), and outputs message(s) returned by the `Model`
+     - `LLMX` then executes command(s), applies patch(es), and outputs message(s) returned by the `Model`
     - Pauses to request approval when necessary
   - The output of one `Turn` is the input to the next `Turn`
   - A `Turn` yielding no output terminates the `Task`

-The term "UI" is used to refer to the application driving `Codex`. This may be the CLI / TUI chat-like interface that users operate, or it may be a GUI interface like a VSCode extension. The UI is external to `Codex`, as `Codex` is intended to be operated by arbitrary UI implementations.
+The term "UI" is used to refer to the application driving `LLMX`. This may be the CLI / TUI chat-like interface that users operate, or it may be a GUI interface like a VSCode extension. The UI is external to `LLMX`, as `LLMX` is intended to be operated by arbitrary UI implementations.

 When a `Turn` completes, the `response_id` from the `Model`'s final `response.completed` message is stored in the `Session` state to resume the thread given the next `Op::UserInput`. The `response_id` is also returned in the `EventMsg::TurnComplete` to the UI, which can be used to fork the thread from an earlier point by providing it in the `Op::UserInput`.

-Since only 1 `Task` can be run at a time, for parallel tasks it is recommended that a single `Codex` be run for each thread of work.
+Since only 1 `Task` can be run at a time, for parallel tasks it is recommended that a single `LLMX` be run for each thread of work.

 ## Interface

- `Codex`
+- `LLMX`
  - Communicates with UI via a `SQ` (Submission Queue) and `EQ` (Event Queue).
 - `Submission`
-  - These are messages sent on the `SQ` (UI -> `Codex`)
+  - These are messages sent on the `SQ` (UI -> `LLMX`)
  - Has an string ID provided by the UI, referred to as `sub_id`
  - `Op` refers to the enum of all possible `Submission` payloads
    - This enum is `non_exhaustive`; variants can be added at future dates
 - `Event`
-  - These are messages sent on the `EQ` (`Codex` -> UI)
+  - These are messages sent on the `EQ` (`LLMX` -> UI)
  - Each `Event` has a non-unique ID, matching the `sub_id` from the `Op::UserInput` that started the current task.
  - `EventMsg` refers to the enum of all possible `Event` payloads
    - This enum is `non_exhaustive`; variants can be added at future dates
@@ -98,16 +98,16 @@ sequenceDiagram
    participant user as User
    end
    box Daemon
-    participant codex as Codex
+    participant llmx as LLMX
    participant session as Session
    participant task as Task
    end
    box Rest API
    participant agent as Model
    end
-    user->>codex: Op::ConfigureSession
-    codex-->>session: create session
-    codex->>user: Event::SessionConfigured
+    user->>llmx: Op::ConfigureSession
+    llmx-->>session: create session
+    llmx->>user: Event::SessionConfigured
    user->>session: Op::UserInput
    session-->>+task: start task
    task->>user: Event::TaskStarted
--- a/llmx-rs/execpolicy/README.md
+++ b/llmx-rs/execpolicy/README.md
@@ -46,7 +46,7 @@ Of note:
 - `foo` is tagged as a `ReadableFile`, so the caller should resolve `foo` relative to `getcwd()` and `realpath` it (as it may be a symlink) to determine whether `foo` is safe to read.
 - While the specified executable is `ls`, `"system_path"` offers `/bin/ls` and `/usr/bin/ls` as viable alternatives to avoid using whatever `ls` happens to appear first on the user's `$PATH`. If either exists on the host, it is recommended to use it as the first argument to `execv(3)` instead of `ls`.

-Further, "safety" in this system is not a guarantee that the command will execute successfully. As an example, `cat /Users/mbolin/code/codex/README.md` may be considered "safe" if the system has decided the agent is allowed to read anything under `/Users/mbolin/code/codex`, but it will fail at runtime if `README.md` does not exist. (Though this is "safe" in that the agent did not read any files that it was not authorized to read.)
+Further, "safety" in this system is not a guarantee that the command will execute successfully. As an example, `cat /Users/mbolin/code/llmx/README.md` may be considered "safe" if the system has decided the agent is allowed to read anything under `/Users/mbolin/code/llmx`, but it will fail at runtime if `README.md` does not exist. (Though this is "safe" in that the agent did not read any files that it was not authorized to read.)

 ## Policy

--- a/llmx-rs/file-search/README.md
+++ b/llmx-rs/file-search/README.md
@@ -1,5 +1,5 @@
 # codex_file_search

-Fast fuzzy file search tool for Codex.
+Fast fuzzy file search tool for LLMX.

 Uses <https://crates.io/crates/ignore> under the hood (which is what `ripgrep` uses) to traverse a directory (while honoring `.gitignore`, etc.) to produce the list of files to search and then uses <https://crates.io/crates/nucleo-matcher> to fuzzy-match the user supplied `PATTERN` against the corpus.
--- a/llmx-rs/linux-sandbox/README.md
+++ b/llmx-rs/linux-sandbox/README.md
@@ -1,8 +1,8 @@
-# codex-linux-sandbox
+# llmx-linux-sandbox

 This crate is responsible for producing:

- a `codex-linux-sandbox` standalone executable for Linux that is bundled with the Node.js version of the Codex CLI
+- a `llmx-linux-sandbox` standalone executable for Linux that is bundled with the Node.js version of the LLMX CLI
 - a lib crate that exposes the business logic of the executable as `run_main()` so that
-  - the `codex-exec` CLI can check if its arg0 is `codex-linux-sandbox` and, if so, execute as if it were `codex-linux-sandbox`
-  - this should also be true of the `codex` multitool CLI
+  - the `llmx-exec` CLI can check if its arg0 is `llmx-linux-sandbox` and, if so, execute as if it were `llmx-linux-sandbox`
+  - this should also be true of the `llmx` multitool CLI
--- a/llmx-rs/process-hardening/README.md
+++ b/llmx-rs/process-hardening/README.md
@@ -1,4 +1,4 @@
-# codex-process-hardening
+# llmx-process-hardening

 This crate provides `pre_main_hardening()`, which is designed to be called pre-`main()` (using `#[ctor::ctor]`) to perform various process hardening steps, such as

--- a/llmx-rs/protocol/README.md
+++ b/llmx-rs/protocol/README.md
@@ -1,6 +1,6 @@
-# codex-protocol
+# llmx-protocol

-This crate defines the "types" for the protocol used by Codex CLI, which includes both "internal types" for communication between `codex-core` and `codex-tui`, as well as "external types" used with `codex app-server`.
+This crate defines the "types" for the protocol used by LLMX CLI, which includes both "internal types" for communication between `llmx-core` and `llmx-tui`, as well as "external types" used with `llmx app-server`.

 This crate should have minimal dependencies.

--- a/llmx-rs/responses-api-proxy/README.md
+++ b/llmx-rs/responses-api-proxy/README.md
@@ -1,23 +1,23 @@
-# codex-responses-api-proxy
+# llmx-responses-api-proxy

 A strict HTTP proxy that only forwards `POST` requests to `/v1/responses` to the OpenAI API (`https://api.openai.com`), injecting the `Authorization: Bearer $OPENAI_API_KEY` header. Everything else is rejected with `403 Forbidden`.

 ## Expected Usage

-**IMPORTANT:** `codex-responses-api-proxy` is designed to be run by a privileged user with access to `OPENAI_API_KEY` so that an unprivileged user cannot inspect or tamper with the process. Though if `--http-shutdown` is specified, an unprivileged user _can_ make a `GET` request to `/shutdown` to shutdown the server, as an unprivileged user could not send `SIGTERM` to kill the process.
+**IMPORTANT:** `llmx-responses-api-proxy` is designed to be run by a privileged user with access to `OPENAI_API_KEY` so that an unprivileged user cannot inspect or tamper with the process. Though if `--http-shutdown` is specified, an unprivileged user _can_ make a `GET` request to `/shutdown` to shutdown the server, as an unprivileged user could not send `SIGTERM` to kill the process.

-A privileged user (i.e., `root` or a user with `sudo`) who has access to `OPENAI_API_KEY` would run the following to start the server, as `codex-responses-api-proxy` reads the auth token from `stdin`:
+A privileged user (i.e., `root` or a user with `sudo`) who has access to `OPENAI_API_KEY` would run the following to start the server, as `llmx-responses-api-proxy` reads the auth token from `stdin`:

 ```shell
-printenv OPENAI_API_KEY | env -u OPENAI_API_KEY codex-responses-api-proxy --http-shutdown --server-info /tmp/server-info.json
+printenv OPENAI_API_KEY | env -u OPENAI_API_KEY llmx-responses-api-proxy --http-shutdown --server-info /tmp/server-info.json
 ```

-A non-privileged user would then run Codex as follows, specifying the `model_provider` dynamically:
+A non-privileged user would then run LLMX as follows, specifying the `model_provider` dynamically:

 ```shell
 PROXY_PORT=$(jq .port /tmp/server-info.json)
 PROXY_BASE_URL="http://127.0.0.1:${PROXY_PORT}"
-codex exec -c "model_providers.openai-proxy={ name = 'OpenAI Proxy', base_url = '${PROXY_BASE_URL}/v1', wire_api='responses' }" \
+llmx exec -c "model_providers.openai-proxy={ name = 'OpenAI Proxy', base_url = '${PROXY_BASE_URL}/v1', wire_api='responses' }" \
    -c model_provider="openai-proxy" \
    'Your prompt here'
 ```
@@ -30,7 +30,7 @@ curl --fail --silent --show-error "${PROXY_BASE_URL}/shutdown"

 ## Behavior

- Reads the API key from `stdin`. All callers should pipe the key in (for example, `printenv OPENAI_API_KEY | codex-responses-api-proxy`).
+- Reads the API key from `stdin`. All callers should pipe the key in (for example, `printenv OPENAI_API_KEY | llmx-responses-api-proxy`).
 - Formats the header value as `Bearer <key>` and attempts to `mlock(2)` the memory holding that header so it is not swapped to disk.
 - Listens on the provided port or an ephemeral port if `--port` is not specified.
 - Accepts exactly `POST /v1/responses` (no query string). The request body is forwarded to `https://api.openai.com/v1/responses` with `Authorization: Bearer <key>` set. All original request headers (except any incoming `Authorization`) are forwarded upstream, with `Host` overridden to `api.openai.com`. For other requests, it responds with `403`.
@@ -40,19 +40,19 @@ curl --fail --silent --show-error "${PROXY_BASE_URL}/shutdown"
 ## CLI

 ```
-codex-responses-api-proxy [--port <PORT>] [--server-info <FILE>] [--http-shutdown] [--upstream-url <URL>]
+llmx-responses-api-proxy [--port <PORT>] [--server-info <FILE>] [--http-shutdown] [--upstream-url <URL>]
 ```

 - `--port <PORT>`: Port to bind on `127.0.0.1`. If omitted, an ephemeral port is chosen.
 - `--server-info <FILE>`: If set, the proxy writes a single line of JSON with `{ "port": <PORT>, "pid": <PID> }` once listening.
 - `--http-shutdown`: If set, enables `GET /shutdown` to exit the process with code `0`.
 - `--upstream-url <URL>`: Absolute URL to forward requests to. Defaults to `https://api.openai.com/v1/responses`.
- Authentication is fixed to `Authorization: Bearer <key>` to match the Codex CLI expectations.
+- Authentication is fixed to `Authorization: Bearer <key>` to match the LLMX CLI expectations.

 For Azure, for example (ensure your deployment accepts `Authorization: Bearer <key>`):

 ```shell
-printenv AZURE_OPENAI_API_KEY | env -u AZURE_OPENAI_API_KEY codex-responses-api-proxy \
+printenv AZURE_OPENAI_API_KEY | env -u AZURE_OPENAI_API_KEY llmx-responses-api-proxy \
  --http-shutdown \
  --server-info /tmp/server-info.json \
  --upstream-url "https://YOUR_PROJECT_NAME.openai.azure.com/openai/deployments/YOUR_DEPLOYMENT/responses?api-version=2025-04-01-preview"
@@ -67,7 +67,7 @@ printenv AZURE_OPENAI_API_KEY | env -u AZURE_OPENAI_API_KEY codex-responses-api-

 Care is taken to restrict access/copying to the value of `OPENAI_API_KEY` retained in memory:

- We leverage [`codex_process_hardening`](https://github.com/openai/codex/blob/main/codex-rs/process-hardening/README.md) so `codex-responses-api-proxy` is run with standard process-hardening techniques.
+- We leverage [`codex_process_hardening`](https://github.com/valknar/llmx/blob/main/llmx-rs/process-hardening/README.md) so `llmx-responses-api-proxy` is run with standard process-hardening techniques.
 - At startup, we allocate a `1024` byte buffer on the stack and copy `"Bearer "` into the start of the buffer.
 - We then read from `stdin`, copying the contents into the buffer after `"Bearer "`.
 - After verifying the key matches `/^[a-zA-Z0-9_-]+$/` (and does not exceed the buffer), we create a `String` from that buffer (so the data is now on the heap).
--- a/llmx-rs/responses-api-proxy/npm/README.md
+++ b/llmx-rs/responses-api-proxy/npm/README.md
@@ -1,13 +1,13 @@
-# @openai/codex-responses-api-proxy
+# @llmx/llmx-responses-api-proxy

-<p align="center"><code>npm i -g @openai/codex-responses-api-proxy</code> to install <code>codex-responses-api-proxy</code></p>
+<p align="center"><code>npm i -g @llmx/llmx-responses-api-proxy</code> to install <code>llmx-responses-api-proxy</code></p>

-This package distributes the prebuilt [Codex Responses API proxy binary](https://github.com/openai/codex/tree/main/codex-rs/responses-api-proxy) for macOS, Linux, and Windows.
+This package distributes the prebuilt [LLMX Responses API proxy binary](https://github.com/valknar/llmx/tree/main/llmx-rs/responses-api-proxy) for macOS, Linux, and Windows.

 To see available options, run:

 ```
-node ./bin/codex-responses-api-proxy.js --help
+node ./bin/llmx-responses-api-proxy.js --help
 ```

-Refer to [`codex-rs/responses-api-proxy/README.md`](https://github.com/openai/codex/blob/main/codex-rs/responses-api-proxy/README.md) for detailed documentation.
+Refer to [`llmx-rs/responses-api-proxy/README.md`](https://github.com/valknar/llmx/blob/main/llmx-rs/responses-api-proxy/README.md) for detailed documentation.
--- a/llmx-rs/stdio-to-uds/README.md
+++ b/llmx-rs/stdio-to-uds/README.md
@@ -1,4 +1,4 @@
-# codex-stdio-to-uds
+# llmx-stdio-to-uds

 Traditionally, there are two transport mechanisms for an MCP server: stdio and HTTP.

@@ -10,7 +10,7 @@ This crate helps enable a third, which is UNIX domain socket, because it has the
 To that end, this crate provides an adapter between a UDS and stdio. The idea is that someone could start an MCP server that communicates over `/tmp/mcp.sock`. Then the user could specify this on the fly like so:

 ```
-codex --config mcp_servers.example={command="codex-stdio-to-uds",args=["/tmp/mcp.sock"]}
+llmx --config mcp_servers.example={command="llmx-stdio-to-uds",args=["/tmp/mcp.sock"]}
 ```

 Unfortunately, the Rust standard library does not provide support for UNIX domain sockets on Windows today even though support was added in October 2018 in Windows 10:
--- a/llmx-rs/tui/styles.md
+++ b/llmx-rs/tui/styles.md
@@ -10,7 +10,7 @@
 - **User input tips, selection, and status indicators:** Use ANSI `cyan`.
 - **Success and additions:** Use ANSI `green`.
 - **Errors, failures and deletions:** Use ANSI `red`.
- **Codex:** Use ANSI `magenta`.
+- **LLMX:** Use ANSI `magenta`.

 # Avoid

--- a/llmx-rs/utils/git/README.md
+++ b/llmx-rs/utils/git/README.md
@@ -1,4 +1,4 @@
-# codex-git
+# llmx-git

 Helpers for interacting with git, including patch application and worktree
 snapshot utilities.