Bidirectional Grok Bot ↔ Codex messaging (app-server + gbot)

[ScriptedAlchemy]

Summary

Enable direct bidirectional communication between Grok Bot agents (via gbot) and Codex tasks/threads, so each side can wake the other the way Codex tasks already message each other ("Sent by ChatGPT from another task").

Motivation

Grok Bot and Codex often work the same repos / machines. Today they cannot coordinate without the human copying context. We want:

• Codex → Grok: Codex agent calls out to a Grok Bot / group with a short status or ask.
• Grok → Codex: Grok Bot injects a follow-up into an existing Codex thread (or starts one), ideally with clear provenance.

Direction of travel (recommended)

1. Codex → Grok (ship first): Codex skill / MCP / plugin wrapping gbot send <bot|group> … (and optionally gbot thread for readback). Auth via existing gbot gateway / Grok Bot app session / CURSOR_ACCESS_TOKEN.
2. Grok → Codex: Small bridge client using documented Codex app-server JSON-RPC (initialize → thread/list|resume → turn/start). Prefer daemon-managed sessions until Desktop re-attaches to the shared control socket.
3. Do not scrape Desktop’s ephemeral CODEX_APP_TOOLS_PIPE_PATH (/tmp/codex-browser-use/*.sock) for product code — that path powers the built-in send_message_to_thread banner but is proprietary and fragile.

Upstream blockers (Desktop live threads)

ChatGPT Desktop currently injects codex_app MCP and runs a private stdio app-server, so ~/.codex/app-server-control/app-server-control.sock is often absent and external clients cannot attach to open Desktop tasks.

Track / pile onto:

• [macOS][regression] codex_app MCP override makes CODEX_APP_SERVER_USE_LOCAL_DAEMON=1 unreachable openai/codex#41014 — codex_app MCP makes CODEX_APP_SERVER_USE_LOCAL_DAEMON=1 unreachable
• [macOS] Desktop 26.820.60940 ignores local App Server daemon openai/codex#41112 — Desktop ignores local App Server daemon

Until fixed, Grok→Codex should target daemon / TUI / codex agents sessions, not today’s Desktop stdio process.

Related local code

• gbot send / gbot thread already exist in this repo
• agent-bundle already has a UDS+WS app-server client pattern (codex-app-server.ts) that can be reused or vendored carefully

Acceptance criteria

• Codex can message a named Grok Bot/group via a documented skill or MCP tool — shipped in feat(plugin): add the grok-bot Agent Bundle plugin (#25) #27 (gbot_send / gbot_thread + skill); Codex skill/MCP: message Grok Bot via gbot send #25 closed
• Grok Bot (or gbot) can list Codex threads on a reachable app-server and turn/start a message — shipped in feat(codex): add gbot codex status, list-threads, and send #28 (gbot codex status|list-threads|send); gbot codex / bridge: inject messages into Codex threads via app-server #26 closed
• Docs cover auth, which Codex process you attach to, and Desktop vs daemon limitations — README sections for plugin install and gbot codex
• No dependency on scraping CODEX_APP_TOOLS_PIPE_PATH — control-socket / daemon only; Desktop private stdio still blocked upstream (#41014, #41112)

Status (2026-09-15): Child issues done, including #37/#38/#39 via #46. Epic stays open for ChatGPT Desktop attach (upstream) and optional Mac Studio smoke of the plugin. Follow-ups #32/#33 and #46 landed the hardening slices.

References

• https://learn.chatgpt.com/docs/app-server
• Research notes from Grok Bot General (2026-09-15): Desktop private stdio vs shared control socket; send_message_to_thread is Desktop MCP, not public RPC

[ScriptedAlchemy]

GPT-6 Pro implementation review (chatgpt.com, 2026-09-14)

Full write-up saved from the review session; key updates to the epic:

Keep / strengthen

• Bidirectional adapters are sound; do not emulate Desktop cross-task UI / scrape CODEX_APP_TOOLS_PIPE_PATH.
• Product contract: authenticated, attributable delivery to a configured app-server route + thread, with receipts — not “make Desktop look like another task messaged it.”
• Scope to Codex tasks, not arbitrary ChatGPT chats.
• Destinations = allowlisted endpoint/profile + threadId, not agent-supplied socket paths.
• Avoid sync deadlocks: send returns a receipt; waiting for a reply is a separate bounded op (correlation ID, hop limit).

Correct assumptions

• Missing socket ≠ proven Desktop-private mode; existing socket ≠ Desktop is using it (#41014 notes daemon can coexist beside private stdio).
• Grok Bot often runs in the cloud — a local skill alone does not reach the Mac socket. Prefer approved local gbot codex first; later a narrow authenticated remote MCP.
• Investigate upstream experimental codex queue / thread/queue/add before inventing our own queue.

Suggested acceptance tweaks for this epic

• Document endpoint ownership + execution location (local exec vs remote MCP)
• Provenance envelope + message/correlation IDs; no auto-ack loops
• Explicitly exclude Desktop-private attach and arbitrary ChatGPT-chat access
• Compatibility matrix (CLI vs Desktop bundled app-server builds)

Source: chatgpt.com chat “Implementation Review…”, model 6 Pro.

[ScriptedAlchemy]

Checked acceptance against main @ ab70a00:

Criterion	State
Codex → Grok MCP/skill	Done (#27 / #25)
Grok → Codex gbot codex	Done (#28 / #26), daemon only
Docs + no pipe scrape	Done
Live ChatGPT Desktop inject	Still blocked upstream (openai/codex#41014, #41112)
Mac Studio plugin smoke	Not done on this host (Ubuntu evidence only)

Leaving this epic open for Desktop + Mac smoke. Release still gated on product calls for history default (#18) and Version Packages (#29).

[ScriptedAlchemy]

Post-land GPT-6 Pro review (#27/#28)

Review chat: https://chatgpt.com/c/6aa89f23-6920-83ea-b98a-a1f155a1ae3f

Verdict: Keep the architecture; do not treat it as production-ready unattended Codex↔Grok yet. Skill-first / thin MCP importing modules is correct. Remaining risk is delivery semantics, transport failure handling, and reliable reply retrieval.

PR #32 is merged (400-char truncation etc.) — do not re-file those.

Follow-up issues filed

• [P1] Preserve send receipts and distinguish rejected, accepted, and unknown delivery #34 [P1] Preserve send receipts / rejected vs accepted vs unknown delivery
• [P1] Bound the Codex WebSocket transport and close resources on every failure #35 [P1] Bound Codex WebSocket transport + close resources on every failure
• [P1] Make gbot_thread bounded without losing complete reply retrieval #36 [P1] Bounded gbot_thread without losing complete reply retrieval
• [P1 before unattended use] Add attributable routes and loop-safe message correlation #37 [P1 before unattended] Attributable routes + loop-safe message correlation
• [P2] Define busy-thread delivery and evaluate Codex’s native queue #38 [P2] Busy-thread delivery + evaluate Codex native queue
• [P2] Complete the machine-readable Codex status and thread-discovery contract #39 [P2] Machine-readable Codex status / thread-discovery contract

Remaining checklist on this epic

• Delivery receipts with rejection/acceptance/ambiguity (no blind retries) — [P1] Preserve send receipts and distinguish rejected, accepted, and unknown delivery #34
• Transport/gateway shutdown, deadlines, malformed-input, resource-budget tests — [P1] Bound the Codex WebSocket transport and close resources on every failure #35
• Bounded complete reply retrieval with explicit truncation/correlation — [P1] Make gbot_thread bounded without losing complete reply retrieval #36
• Real intended-Mac Codex→Grok→Codex round trip incl. approvals + loop prevention — [P1 before unattended use] Add attributable routes and loop-safe message correlation #37
• Supported runtime/schema/deployment versions + status diagnostics — [P2] Complete the machine-readable Codex status and thread-discovery contract #39
• Busy-thread / native-queue decision — [P2] Define busy-thread delivery and evaluate Codex’s native queue #38
• Private Desktop attachment stays out of scope / upstream-blocked (#41014 / #41112)

Must-fix before daily unattended use: #34, #35, #36 (and #37 for attributable routes). Treat turnId as acknowledged submission, not completed work.