Expose built-in Chat / Quick Chat as a supported Codex skill or app-server capability

What variant of Codex are you using?

Codex App on macOS (unified ChatGPT + Codex desktop app), with Codex skills and app-server integrations

What feature would you like to see?

Summary

The unified ChatGPT + Codex desktop app now includes a built-in Chat / Quick Chat surface for ordinary ChatGPT conversations.

I would like Codex skills to be able to invoke this built-in Chat through a supported, capability-gated tool or app-server interface, instead of automating chatgpt.com through the in-app browser.

Use case

I maintain Codex skills that ask a ChatGPT model for a second opinion on:

• bugs and root-cause analysis
• architecture and refactoring decisions
• repository reviews
• implementation validation

Today, these skills must:

1. Open chatgpt.com in the Codex in-app browser.
2. Create or reuse a browser conversation.
3. Select an eligible model or mode.
4. Enter the prompt through UI automation.
5. Wait for completion and scrape the response.

This works, but it is fragile and duplicates functionality now available directly in the desktop app.

Requested behavior

Please expose a supported way for a Codex skill or turn to consult the built-in Chat surface.

A minimal first version could be a host-owned, one-shot consultation tool with behavior similar to:

• Discover whether built-in Chat is available.
• Submit text and user-approved attachments.
• Request a model or mode available under the signed-in user's ChatGPT plan, including Pro mode when the user is entitled to it.
• Stream or wait for the response.
• Return the final response to the originating Codex turn.
• Optionally return a conversation reference when the chat is persisted.

The exact method and namespace are not important. This could be implemented as:

• a host-provided dynamic tool,
• an app-server capability, or
• a higher-level ChatGPT consult primitive.

A one-shot consultation capability would be sufficient for the initial use case. Full conversation CRUD could be considered separately.

Why existing Codex APIs do not cover this

The public app-server exposes Codex thread and turn operations such as thread/start, thread/read, and turn/start. Those methods operate Codex agent tasks, not ordinary ChatGPT conversations.

The current public request definitions do not expose the built-in Chat / Quick Chat surface:

https://github.com/openai/codex/blob/main/codex-rs/app-server-protocol/src/protocol/common.rs

Using the Responses API separately is also not equivalent because it requires a separate API integration and billing path instead of using the ChatGPT capabilities already available to the signed-in desktop user.

Safety and privacy expectations

This capability should not bypass subscription, model, workspace, or rate-limit restrictions.

Suggested safeguards:

• Require explicit user opt-in or approval before a skill sends content to Chat.
• Show which text, files, and images will be shared.
• Do not expose unrelated personal ChatGPT history by default.
• Clearly identify chats or messages created by a Codex skill.
• Support cancellation and normal timeout/error handling.
• Make availability discoverable so skills can fall back gracefully.
• Avoid requiring skills to call undocumented ChatGPT backend endpoints.
• Allow administrators to disable the capability for managed workspaces.

Acceptance criteria

• A Codex skill can detect whether the capability is available.
• It can send an approved prompt without controlling the desktop UI or browser DOM.
• It can receive the assistant response through a documented interface.
• Model or mode selection is validated against the user's actual entitlement.
• The user can see or audit that Codex initiated the consultation.
• The capability does not provide implicit access to unrelated ChatGPT conversations.
• Skills can fall back to another provider or the in-app browser when unavailable.

This would make second-opinion and review workflows substantially more reliable while preserving a clear user-consent and privacy boundary.

Additional information

Related but distinct issue:

• #31956 requests that Chat open in a full window by default. This request is specifically about a supported programmatic capability for Codex skills and app-server clients.

I understand that some desktop-host implementation may not be part of the public repository.

Following the repository's contribution policy, I am opening an issue before attempting an implementation. If the maintainers agree on the capability shape and identify a public app-server or protocol portion suitable for external contribution, I would be interested in contributing after an explicit invitation.