Skip to content

Allow Codex Desktop to connect to an externally managed App Server #40134

Open
Open
Allow Codex Desktop to connect to an externally managed App Server#40134
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesenhancementNew feature or request

Description

@gxthrj
gxthrj
opened on Aug 22, 2026

What variant of Codex are you using?

App

What feature would you like to see?

Codex App Server already supports stdio, WebSocket, and Unix socket transports, and the Codex CLI can connect to an existing App Server with codex --remote. Codex Desktop does not appear to provide a documented way to connect to an externally managed App Server.

Please allow Codex Desktop to connect to an existing App Server endpoint at startup, for example:

open -a Codex --args --remote unix:///path/to/codex-app-server.sock

or:

open -a Codex --args --remote ws://127.0.0.1:4500

A persistent setting such as desktop.app_server_endpoint would also be useful.

Required behavior:

  1. Desktop and another trusted local client can connect to the same App Server.
  2. Threads created by either client appear immediately in Desktop.
  3. Both clients receive thread and turn notifications.
  4. Desktop can navigate directly to externally created threads.
  5. Either client can append turns to an idle thread.
  6. Active-writer and approval ownership are explicitly defined.
  7. Disconnecting one client does not leave a lock that blocks the other.
  8. Local WebSocket and Unix socket connections support capability-token authentication.
  9. Existing codex://threads/<thread-id> navigation works for externally created threads.

The App Server must support multiple collaborating clients, not merely multiple transport connections.

Additional information

Related issues document narrower symptoms of the current split-process approach:

This request is broader than those bugs: it asks for a supported Desktop startup/configuration mode that connects Desktop and trusted local integrations to the same App Server instance, with explicit multi-client lifecycle and ownership semantics.

Official App Server documentation: https://learn.chatgpt.com/docs/app-server

Activity

  1. github-actions
    added
    enhancementNew feature or request
    appIssues related to the Codex desktop app
    app-serverIssues involving app server protocol or interfaces
    on Aug 22, 2026

  2. SIMON-WORLD commented on Sep 3, 2026

    @SIMON-WORLD
    SIMON-WORLD
    on Sep 3, 2026 – with ChatGPT Codex Connector

    Concrete production use case for this request from a trusted local orchestration integration.

    I currently have a working flow roughly like:

    ChatGPT-side orchestrator
→ authenticated local tunnel/control plane
→ local orchestration service
→ independently managed codex app-server
→ Codex

    The external App Server path itself works well for sustained execution. In a recent Windows production test, a thread created this way ran for roughly 16 minutes, modified files, ran tests, committed and pushed its work, and remained durably readable through App Server afterward.

    The operational gap was human visibility: because the orchestrator and Codex Desktop were attached to separate App Server processes, the successfully created thread was not live-registered in the already-running Desktop sidebar. That is the same core failure mode tracked in #36363, now reproduced in a real Windows orchestration workload rather than a short synthetic thread.

    For this use case, returning to UI automation is not desirable. The App Server protocol is already the appropriate execution boundary; what is missing is a supported way for Desktop and a trusted local controller to participate in the same authoritative server/session plane.

    Current upstream work appears to make this direction even more relevant:

    • App Server already broadcasts thread lifecycle notifications such as thread/started to connections of the running server.
    • The local Unix-socket control transport is supported on Windows.
    • The new managed App Server daemon now supports Windows as well (Support the app-server daemon on Windows #42405), providing infrastructure for sharing a background App Server across Codex sessions.

    I do not assume that this means Desktop can already attach to an externally managed daemon; that is still the capability requested by this issue.

    One additional distinction may be important for the eventual contract: sharing the App Server appears to solve only part of the problem. #40935 reports that a custom client connected to the exact App Server process used by Desktop can create a task that is immediately visible/openable in Desktop, while the App Server projectId and Desktop saved-project assignment still remain separate.

    So the desired end state for an external orchestrator would ideally include two explicit contracts:

    1. one shared App Server lifecycle/notification plane for thread creation, turns, writer ownership, approvals, and reconnect; and
    2. a supported Desktop project/catalog mapping contract, rather than requiring external clients to infer or mutate Desktop-private project state.

    For our integration, the important properties would be deterministic thread identity, immediate Desktop visibility, explicit active-writer/approval ownership, reconnect without duplicate execution, and no direct access to Desktop databases or UI automation.

    I can provide a sanitized sequence diagram and App Server request/notification timeline from the production reproduction if useful.

  3. yvettehuang199212-sketch commented on Oct 9, 2026

    @yvettehuang199212-sketch
    yvettehuang199212-sketch
    on Oct 9, 2026 – with ChatGPT Codex Connector

    我们需要一个运行在同一台 Windows 电脑上的受限桥接程序，将输入提交给 Codex Desktop 已有线程，不创建替代线程。
    请确认当前受支持的接入方式及最低版本：

    1. 如何连接桌面实际使用的同一个 App Server，并完成受支持的认证？
    2. 如何在服务端保证忙碌时排队或明确拒绝，而不向当前运行追加输入？
    3. 哪个接口返回单条提交的接纳编号？请求超时后如何查询接纳状态、避免重复执行？
    4. 如何保留原线程的沙箱、工具审批及权限设置？
      如果 Windows 桌面暂不支持，请明确说明。本文不附会话、凭证、业务材料或私有标识。

    关联：#41014

  4. dwyler741 commented on Oct 12, 2026

    @dwyler741
    dwyler741
    on Oct 12, 2026

    Could maintainers clarify the currently supported external-client contract for macOS Codex Desktop using app-server 0.162.0-alpha.17.2?

    The integration needs an external UI to use Desktop's actual host and persistent conversation, including its authorized tools and question, approval, and result callbacks. The official app-server documentation describes transports, but does not establish how an external client binds to the already-running Desktop host.

    1. What documented endpoint and client-registration mechanism provides that binding?
    2. Can Desktop and the external client share the same persistent thread and callbacks, with defined active-writer and approval ownership?
    3. If this connection is not currently exposed, what recommended integration pattern and minimum version preserve Desktop capabilities and persistent reopening?

    Please point to the public contract or documentation. No credentials, private session identifiers, user content, or logs are attached.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions