mimo2codex Documentation

repository·main·Indexed 20 days ago

https://github.com/7as0nch/mimo2codex

A local protocol proxy that enables OpenAI Codex CLI and desktop applications to work with various LLM providers. It translates between the Codex Responses API and OpenAI Chat Completions-compatible APIs, supporting providers like Xiaomi MiMo (V2.5 Pro), DeepSeek V4 Pro, Ollama, and LM Studio. Features include a web admin console, BYOK (Bring Your Own Key) support, OAuth integration for GitHub and Gitee, and a docbackend service for interactive documentation features.

Tokens
112.1K
Snippets
292
Records
482
Agent score
66%

What's inside mimo2codex

  1. Overview of mimo2codex

    main

    mimo2codex is a local proxy designed to allow the latest OpenAI Codex CLI and desktop applications to communicate with virtually any modern Large Language Model (LLM). It acts as a protocol shim that translates between the Codex Responses API and upstream OpenAI Chat Completions-compatible APIs (such as Qwen, GLM, Kimi, vLLM, Ollama, or LM Studio) or native Responses APIs.

    Key Capabilities:

    • Protocol Translation: Translates Codex's Responses API $\leftrightarrow$ upstream Chat Completions on the fly.
    • Multi-provider Routing: Routes requests to different providers (e.g., Xiaomi MiMo V2.5, DeepSeek V4 Pro, or generic providers) based on the model field in the request.
    • Feature Support: Supports tool calling, web search (MiMo native web_search), vision, reasoning (including reasoning_content round-trips), and the MCP namespace.
    • Admin Console: Provides a web interface at http://127.0.0.1:8788/admin/ for managing the model catalog, viewing chat logs, monitoring token stats, and configuring providers using SQLite persistence.
  2. How mimo2codex works as a protocol proxy

    main

    mimo2codex acts as a thin protocol translation layer between the latest OpenAI Codex (which requires the wire_api = "responses" format) and upstream providers that use the standard OpenAI Chat Completions API (like Qwen, GLM, Kimi, Ollama, or LM Studio).

    Core Mechanism

    • Protocol Translation: It translates Codex's Responses API calls into upstream Chat Completions calls in real-time.
    • Automatic Routing: It routes requests to different providers based on the model field sent by the Codex client.
    • Multi-Provider Support: A single running process can manage multiple providers (e.g., MiMo, DeepSeek, and custom generic providers) simultaneously.
    • Feature Support: It supports tool calling (function calling), parallel tools, MCP namespaces, web search (via MiMo native web_search), and correctly passes back multi-turn reasoning_content.
  3. Understand model routing priority and runtime overrides

    main

    As of v0.5.27, the priority for determining which model to use has changed to prevent runtime overrides from silently hijacking explicitly configured Codex models. The routing priority is now:

    1. Client Model: If a registered provider with a valid key recognizes the model ID.
    2. Runtime Override: Used only when the model ID is not found in any provider's directory.
    3. Default Provider: The fallback mechanism.

    This ensures that if Codex explicitly requests a model (e.g., mimo-v2.5-pro), it is respected. Runtime overrides now act as an 'intelligent fallback' for unrecognized model IDs rather than an unconditional override.

  4. How to hide the macOS Dock icon for menu-bar-only apps

    main

    To create a 'menu-bar-only' agent app that does not appear in the macOS Dock or Cmd+Tab switcher, set the LSUIElement key to true within the mac.extendInfo section of your electron-builder.yml. This provides a declarative way to ensure the app behaves like a background agent without startup flicker.

    mac:
      # ... other mac config ...
      extendInfo:
        LSUIElement: true
        NSHumanReadableCopyright: "© 2026 chengj"
  5. Use Kimi (Moonshot) presets

    main

    mimo2codex includes a specific preset for Kimi (Moonshot AI) to ensure compatibility. When you enter https://api.moonshot.cn/v1 or moonshot.ai in the provider settings, the system automatically applies the dropReasoningEffort: true configuration. This prevents 400 errors caused by Kimi not recognizing the reasoning_effort parameter.

    Supported Kimi Models:

    • kimi-k2.6 / kimi-k2.5 / kimi-k2-thinking / kimi-k2-thinking-turbo
    • moonshot-v1-{8k,32k,128k}
  6. How MiniMax compatibility features work

    main

    MiniMax requires specific request sanitization that other providers (like OpenAI or DeepSeek) do not. Instead of applying these changes globally, mimo2codex uses an opt-in system via the features object in the provider configuration.

    Setting features.minimaxCompat: true automatically enables the following five sub-features:

    • dropNullStrict: Removes tools[*].function.strict: null.
    • dropNullContent: Removes content: null from assistant messages containing tool calls.
    • dropToolChoiceAuto: Removes explicit tool_choice: "auto".
    • mergeSystemMessages: Merges multiple role: "system" messages into a single message at the start of the array.
    • extractThinkTags: (Response-side) Extracts inline <think>...</think> blocks from the content field and moves them to reasoning_content to align with DeepSeek-R1 behavior.

    Manual overrides: If you encounter specific errors, you can manually toggle these (which are NOT included in the minimaxCompat preset):

    • dropStreamOptions: Removes the stream_options field. Use this only if the upstream returns a 400 error, as it disables usage statistics in the admin dashboard.
    • dropParallelToolCalls: Removes the parallel_tool_calls field.
  7. Migrate Codex sessions between providers

    main

    The Session Manager allows you to browse and migrate Codex sessions across different providers.

    Key features:

    • View all sessions: The Session Manager tab reads the Codex state database (~/.codex/state_<N>.sqlite) to show sessions grouped by provider → project (cwd) → session, regardless of the currently active provider.
    • Migration: You can migrate a session to a different provider. This rewrites the session's model_provider in the database and the rollout file's session_meta.
    • Batch Migration: You can select multiple sessions via checkboxes and use "Migrate selected" to move them to a single provider at once.

    Safety Mechanisms:

    • Backups: Before any migration, mimo2codex snapshots the entire state database (including -wal and -shm files) and the rollout file into ~/.codex/.m2c-backups/sessions/<ts>/.
    • Lock Protection: Migration will fail with a 409 codex_running error if Codex Desktop is currently running and holds a lock on the database. Ensure Codex is closed before migrating.
  8. Understand the two network links in mimo2codex

    main

    mimo2codex operates using two distinct network links. Understanding the difference is critical for troubleshooting connectivity issues:

    1. Client $\rightarrow$ mimo2codex (Local Loopback): The connection from your Codex CLI or Desktop to the local mimo2codex instance (typically 127.0.0.1:8788). Failures here usually result in ECONNREFUSED and indicate that mimo2codex is not running or the port is occupied.
    2. mimo2codex $\rightarrow$ Upstream API (Outbound HTTPS): The connection from mimo2codex to the LLM provider (e.g., DeepSeek, OpenAI, MiMo). Failures here typically result in 502 Bad Gateway, ETIMEDOUT, or ENOTFOUND and are usually caused by proxy, VPN, or firewall settings.
  9. Understand the mimo2codex Desktop Shell Architecture

    main

    The desktop shell is implemented using a sidecar model. Instead of compiling the existing Node.js CLI into a single binary (which has ESM and native module limitations), the Electron main process supervises the CLI as an untouched child process using child_process.spawn.

    Key architectural details:

    • Isolation: All desktop-specific code resides in package/desktop/ with its own package.json and node_modules, ensuring the root npm package and Docker images remain unaffected.
    • Persistence: All persistent paths (settings, logs, etc.) resolve from app.getPath("userData") rather than app.getAppPath(). This makes the application immune to macOS Gatekeeper translocation issues.
    • Distribution: The application is packaged via electron-builder into four artifacts (Windows/macOS x64/arm64) and distributed through GitHub Releases.
  10. Check for desktop version updates

    main

    The desktop client performs passive update checks by comparing the local version against the latest GitHub Release tag.

    Version Logic

    • The check fetches the latest tag from the GitHub API.
    • It uses parseDesktopVersion to extract [major, minor, patch] from tags like v0.5.0-desktop.
    • An update is considered available via isMinorAhead if the latest version has a higher major version OR a higher minor version than the current version.

    UI Integration

    Instead of intrusive popups, the application uses setUpdateAvailable(true) to inject a ● Update available — Get latest item into the Tray menu, which links to the download page.

    // Logic used to determine if a menu item should be shown
    import { isMinorAhead, parseDesktopVersion } from './updateCheck.js';
    
    const latest = parseDesktopVersion("v0.6.0-desktop"); // [0, 6, 0]
    const current = parseDesktopVersion("v0.5.2-desktop"); // [0, 5, 2]
    
    if (latest && current && isMinorAhead(current, latest)) {
      // Trigger tray menu update
    }
  11. Understand the mimo2codex Desktop Architecture

    main

    The desktop application operates using a sidecar pattern. The Electron Main Process acts as a supervisor for a standalone mimo2codex-sidecar binary (compiled from the existing CLI via @yao-pkg/pkg).

    Key Architectural Components:

    • Electron Main Process: Manages the application lifecycle, tray/menu icon, settings window, logs window, and the sidecar process.
    • Sidecar Manager: Uses child_process.spawn() to run the mimo2codex-sidecar binary. It monitors the process and handles automatic restarts (up to 1 retry) or displays error notifications if the sidecar fails to start.
    • Data Isolation: The desktop version uses the OS userData directory (e.g., %APPDATA%\mimo2codex on Windows or ~/Library/Application Support/mimo2codex on macOS) to store .env, runtime.json, and logs. This ensures it remains physically isolated from the CLI version's ~/.mimo2codex/ directory.
    • Port Management: Defaults to port 8788. If the port is occupied, the app automatically probes for the next available port and records it in userData/runtime.json.
  12. Understand the `INFO backfilled placeholder reasoning_content` log message

    main

    This log message is not an error. It appears when you enable 'Thinking Mode' in a conversation where previous assistant messages do not contain reasoning_content (e.g., if you previously had thinking mode turned OFF or if the client didn't return reasoning items).

    Providers like MiMo and DeepSeek V4 strictly require reasoning_content to be present in the entire conversation history when thinking mode is active. To prevent an upstream 400 Bad Request error, mimo2codex automatically injects a placeholder string "(this turn ran without thinking mode)" into those historical messages.

    Key details:

    • Functionality: Your current request will still use thinking mode.
    • Impact: The placeholder makes the history compatible with the upstream API requirements without requiring you to start a new session.
    • When to start a new session: If you feel the conversation history is too 'polluted' by these placeholders, starting a new session will clear the history and stop the injection.
    [2026-05-20T02:42:14.123Z] INFO backfilled placeholder reasoning_content onto 1 historical assistant message(s) so thinking can stay ON for this request. These turns originally ran with thinking OFF (or the client didn't echo reasoning items). Placeholder text: "(this turn ran without thinking mode)".