RFC: add a native ChatGPT delegation skill and decouple advisory workflow from browser transport

[genforAI]

Summary

The new ChatGPT desktop app now places Chat, Work, and Codex in one application, and users can open Quick Chat while working in Codex. This changes the product surface around Oracle: for a human, switching from Codex to ChatGPT no longer requires a separate Chrome automation flow.

However, the valuable part of Oracle is not only the browser driver. Oracle also provides:

• deliberate second-model delegation;
• prompt and file bundling;
• model / reasoning-effort policy;
• session provenance and recovery;
• follow-up handling;
• an advisory boundary where the second model does not directly edit the repository.

I would like to propose preserving the existing oracle skill, while adding a new transport-neutral skill intended for the unified ChatGPT/Codex era.

This is an RFC, not a claim that Codex currently exposes a supported agent-callable API for creating ChatGPT Chat conversations. OpenAI's current documentation describes the unified UI and Quick Chat, but also says Codex workflows and history remain separate. The proposal should therefore fail closed unless an official native capability is actually exposed.

Official product context:

• https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex
• https://help.openai.com/en/articles/20001276-moving-to-the-new-chatgpt-desktop-app

Current Oracle direction

Oracle currently presents itself as a CLI and MCP server that sends a context bundle through an API or a signed-in browser. The bundled skills/oracle/SKILL.md is strongly transport-aware and currently recommends ChatGPT browser mode for the main GPT workflow.

The repository has already adapted to the new Chat / Work UI:

• Browser enhancement: normalize ChatGPT Work sessions to Chat #315 identified that Oracle could accidentally submit into Work.
• feat(browser): normalize ChatGPT Work sessions to Chat #316 added browser-side normalization from Work to Chat.
• Question: supporting additional ChatGPT tools in browser mode #341 asks whether browser mode should automate more ChatGPT tools, but that still expands the CDP/UI automation surface rather than introducing a native host path.

Those are useful compatibility changes, but they do not address the longer-term architectural question: should the advisory workflow remain coupled to browser automation when the host application may eventually expose a first-party ChatGPT delegation capability?

Proposed direction

1. Keep the existing Oracle skill

Do not remove or deprecate skills/oracle.

It remains useful for:

• cross-provider panels;
• API execution;
• browser execution outside the ChatGPT desktop host;
• MCP clients such as Claude Code and Cursor;
• session recovery, artifacts, Deep Research, and manual render/copy fallback.

2. Add a new transport-neutral advisory skill

Possible names:

• oracle-advisor
• chatgpt-advisor
• oracle-delegate

The exact name is less important than keeping this separate from the current browser-oriented golden path.

The skill would define when and how to ask a second model, while treating the execution transport as replaceable.

Suggested request contract:

ask_advisor(
  prompt,
  files,
  new_session=true,
  desired_model,
  desired_effort,
  preserve_conversation,
  output_contract
)

Suggested result contract:

answer
session_ref
conversation_ref_or_url
requested_model
observed_or_effective_model
requested_effort
observed_or_effective_effort
transport
selection_evidence
uncertainties

3. Capability-based backend routing

A possible backend order:

1. Official host-native ChatGPT capability, only when the runtime explicitly exposes one.
2. Oracle API backend, when configured and authorized.
3. Oracle browser backend, preserving today's functionality.
4. Render/manual-paste fallback.

The new skill should never infer native availability merely because Chat and Codex appear in the same desktop UI.

A native backend should require an explicit, supported capability for at least:

• create a new Chat conversation;
• select or request a model;
• select or request reasoning effort;
• submit text and permitted attachments;
• wait for completion;
• read the final response;
• return a durable conversation/session reference.

If those primitives are unavailable, the skill should report that native delegation is unavailable and choose an allowed fallback rather than controlling private application internals.

Suggested phased implementation

Phase 0 — architecture and capability matrix

• Add a short design document describing the advisory layer versus execution transports.
• Document the current capability matrix for API, browser, render, and hypothetical native host execution.
• Explicitly state that the unified desktop UI does not by itself prove agent-callable native delegation.

Phase 1 — new skill only

• Add the transport-neutral skill.
• Reuse existing Oracle CLI/MCP backends.
• Preserve the current oracle skill unchanged for compatibility.
• Make routing and provenance requirements explicit.

This phase can ship without any unsupported native integration.

Phase 2 — adapter seam

• Introduce a small advisor backend interface around the existing API/browser/render paths if maintainers think it belongs in Oracle core.
• Keep browser-specific model-picker and recovery logic behind the browser adapter.

Phase 3 — official native backend

• Implement only after the ChatGPT/Codex host exposes a documented tool, plugin action, MCP method, or other supported interface.
• Prefer feature detection over version detection.

Why a second skill instead of rewriting skills/oracle

• Existing users and non-ChatGPT coding agents still need the current Oracle workflow.
• The current skill contains valuable operational guidance for browser sessions, attachments, timeouts, and recovery.
• A new skill allows a cleaner advisory abstraction without pretending browser details are universal.
• It gives Oracle a migration path instead of forcing an all-at-once rewrite.

Non-goals

• Do not reverse-engineer private ChatGPT desktop IPC or undocumented local endpoints.
• Do not extract cookies, access tokens, or account credentials.
• Do not remove browser mode.
• Do not claim that Quick Chat is already callable by the Codex agent.
• Do not silently fall back from a requested Pro/high-effort run to an unverified model.
• Do not let the advisor directly modify the repository unless a separate, explicit workflow requests that behavior.

Acceptance criteria for the RFC

• Maintainer decision on whether this belongs in Oracle or a companion skill repository.
• Agreed boundary between advisory policy and transport implementation.
• Agreed name and minimal schema for the new skill.
• Explicit fallback and provenance rules.
• No unsupported native implementation required for the first merge.

Open questions

1. Would maintainers prefer the new skill to live in this repository or in the broader agent-skills collection?
2. Should the transport-neutral contract be skill-only initially, or also become an MCP/CLI abstraction?
3. Should browser remain the automatic fallback, or should native-unavailable runs require explicit user approval before starting Chrome automation?
4. Should the native path preserve a visible ChatGPT conversation by default, while browser one-shots retain the existing archive policy?
5. Is oracle-advisor a better name than chatgpt-advisor, given that Oracle supports multiple providers?

I would be happy to help draft the Phase 0 design document and a minimal new skill once the product boundary is agreed.

[genforAI]

Important surface distinction

A clarification after comparing the merged browser work with OpenAI's current product documentation:

• Browser enhancement: normalize ChatGPT Work sessions to Chat #315 / feat(browser): normalize ChatGPT Work sessions to Chat #316 operate against the ChatGPT web application loaded in Oracle-controlled Chrome. Their Chat/Work detection inspects chatgpt.com DOM state and normalizes that browser page before model/effort selection. They do not integrate with the native top-left ChatGPT/Codex switcher in the unified desktop application.
• The unified desktop app is a separate product surface. OpenAI documents a global ChatGPT / Codex switcher, then a Chat / Work toggle under ChatGPT. From the Codex view, a human can select New chat to open Quick Chat.
• The Codex CLI remains documented as a local coding agent. Signing into the CLI with a ChatGPT account authenticates Codex usage; it does not currently expose a documented Chat/Work mode, Quick Chat command, or supported API for creating and reading ordinary ChatGPT conversations.

This strengthens the capability-detection requirement in the RFC. A possible native backend would initially be relevant to the desktop host only, unless OpenAI later exposes the same capability to CLI/IDE/plugin clients. The new advisory skill should therefore distinguish at least:

host = desktop | cli | ide | other
native_chat_capability = available | unavailable | unknown

Expected current behavior:

• Desktop with a future documented agent-callable Chat capability: native path may be selected.
• Desktop with only a human-visible Quick Chat surface: report native automation unavailable; use an allowed fallback.
• CLI / IDE today: do not infer ChatGPT Chat access from ChatGPT sign-in; use API, Oracle browser, or render fallback.

Official product references:

• https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex
• https://help.openai.com/en/articles/20001276-moving-to-the-new-chatgpt-desktop-app
• https://github.com/openai/codex

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 5, 2026, 12:25 PM ET / 16:25 UTC.

Summary
Keep open for a maintainer product decision: current Oracle supports API, browser, and render paths, but has neither a native desktop-host transport nor a transport-neutral advisory contract. Likely related people: Peter Steinberger (high confidence) and Alex Lapchenko (medium confidence).

Reproducibility: not applicable. this is an RFC rather than a report of broken behavior; current source establishes the existing API/browser/render boundary.

Root-cause cluster
Relationship: canonical
Canonical: #355
Summary: This is the canonical proposal for a transport-neutral advisory contract; the related browser-tools question is adjacent but does not own the native-host or consent boundary.

Members:

• adjacent_distinct: Question: supporting additional ChatGPT tools in browser mode #341 - It considers additional tools within existing browser automation rather than a transport-neutral advisory layer or native desktop-host capability.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Should Oracle own a skill-only advisory contract now, with native-unavailable runs requiring an explicit caller-selected API, browser, or render fallback?	Adopt a scoped Phase 0 in Oracle: Approve a design-only, skill-first contract that preserves existing Oracle behavior and requires explicit fallback selection until an official native capability exists.

Why: The repository has reusable execution paths, but ownership, public contract scope, and consent behavior for browser fallback are product choices rather than mechanical repairs.

Next step
A maintainer must choose the advisory layer’s ownership and native-unavailable fallback policy before implementation can be safely scoped.

Review details

Best possible solution:

Approve a small Phase 0 design that defines advisory provenance, explicit native-unavailable behavior, and ownership before any new skill, MCP contract, or transport adapter is implemented.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is an RFC rather than a report of broken behavior; current source establishes the existing API/browser/render boundary.

Is this the best way to solve the issue?

Unclear: the staged skill-first approach avoids unsupported native integration, but maintainers must choose ownership and browser-fallback consent before it is the best solution.

AGENTS.md: found, but no applicable review policy affected this item.

Remaining risk / open question:

• The fallback policy determines whether a request may start signed-in browser automation and needs an explicit consent boundary.
• Implementing a native backend before a documented host capability exists would risk relying on unsupported private application surfaces.

Codex review notes: model internal, reasoning high; reviewed against d0898f4bd765.

Label changes

Label justifications:

• P3: This is a forward-looking architecture and skill-scope RFC with no current user-facing regression established.

Evidence reviewed

What I checked:

• Current execution boundary: The MCP consult schema accepts only api or browser engines; there is no native-host transport or advisory contract. (src/mcp/types.ts:26, d0898f4bd765)
• Current browser implementation: Browser mode is documented as Chrome/CDP or signed-in web execution, confirming that the existing ChatGPT path is browser transport rather than desktop-host integration. (docs/browser-mode.md:3, d0898f4bd765)
• Released behavior: The v0.17.0 release documents automatic API-or-browser selection and the same API/browser engine set, so the requested abstraction is not already shipped. (README.md:62, 0f46c76a0d1d)
• Feature history: Recent browser model-selection work touched the bundled Oracle skill, while the repository history attributes the documented product boundary to Peter Steinberger; this supports routing the contract decision to the existing product and browser owners. (skills/oracle/SKILL.md:8, a1825d09aede)
• Related work boundary: Merged feat(browser): normalize ChatGPT Work sessions to Chat #316 normalizes ChatGPT web Chat/Work sessions, while open Question: supporting additional ChatGPT tools in browser mode #341 asks about more browser tools; neither supplies a native-host delegation contract. (f7ab9d39f11f)

Likely related people:

• Peter Steinberger: Current product-boundary documentation is attributed to Peter in blame, and the sampled feature-history shortlog shows the strongest sustained involvement in this surface. (role: primary product and feature-history contributor; confidence: high; commits: 0f46c76a0d1d, d0898f4bd765; files: README.md, docs/agents.md, skills/oracle/SKILL.md)
• Alex Lapchenko: Recent commit a1825d0 updated browser thinking-time behavior and the bundled skill, directly adjacent to the existing browser-oriented delegation path. (role: recent browser model-selection contributor; confidence: medium; commits: a1825d09aede; files: skills/oracle/SKILL.md, docs/browser-mode.md)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[genforAI]

To clarify the intended execution path: the proposed native backend would not launch or attach to Chrome, navigate to chatgpt.com, or reuse Oracle's CDP browser automation. Its purpose is to let a Codex agent delegate to Chat/Quick Chat through a supported capability exposed by the unified ChatGPT desktop host, entirely within the same desktop application. Oracle's existing browser engine should remain a separate legacy backend, not an automatic fallback. If the native capability is unavailable, the new skill should fail closed or ask the caller to explicitly choose API, browser, or render mode.