Summary
When a Codex session run through this plugin calls a ChatGPT connector tool (the codex_apps MCP server — DainOS, GitHub, Slack, etc.), the call is refused before it runs. The root cause is that the plugin's app-server JSON-RPC client stubs every inbound server→client request with a -32601 error, so the approval/elicitation request that connector tool calls depend on is never answered.
Where
scripts/lib/app-server.mjs (plugin v1.0.6):
handleServerRequest(message) {
this.sendMessage({
id: message.id,
error: buildJsonRpcError(-32601, `Unsupported server request: ${message.method}`)
});
}
Inbound messages that carry both an id and a method (server→client requests, including approval elicitations) are routed here and unconditionally rejected. Only notifications (method, no id) are handled, via notificationHandler.
Impact
Sol/Codex cannot use any ChatGPT connector through the plugin's runners:
- The background rescue agent (
codex:rescue) returns user rejected MCP tool call instantly.
codex mcp-server (driven from Claude Code) and plain codex exec hang on the unanswered elicitation (observed ~20+ min at 0% CPU).
Repro
- Sign in to Codex with a ChatGPT account that has at least one connector/app enabled.
- From the plugin (or
codex exec), ask the model to call any connector tool (a read-only one is enough).
- Observe
user rejected MCP tool call (rescue agent) or an indefinite hang (codex exec / codex mcp-server).
Workaround
codex exec --dangerously-bypass-approvals-and-sandbox bypasses the approval handshake entirely and the connector call succeeds. Note: approval_policy = "never" in ~/.codex/config.toml alone is not sufficient — the connector elicitation still blocks. The interactive codex TUI works because it answers the elicitation itself.
Suggested fix
Implement handleServerRequest to respond to approval / elicitation requests (auto-approve per the session's approval_policy, or surface them to the caller) instead of blanket-rejecting with -32601.
Environment
- Plugin:
codex@openai-codex v1.0.6 (marketplace openai/codex-plugin-cc)
- codex-cli 0.144.4
- Claude Code on macOS
Summary
When a Codex session run through this plugin calls a ChatGPT connector tool (the
codex_appsMCP server — DainOS, GitHub, Slack, etc.), the call is refused before it runs. The root cause is that the plugin's app-server JSON-RPC client stubs every inbound server→client request with a-32601error, so the approval/elicitation request that connector tool calls depend on is never answered.Where
scripts/lib/app-server.mjs(plugin v1.0.6):Inbound messages that carry both an
idand amethod(server→client requests, including approval elicitations) are routed here and unconditionally rejected. Only notifications (method, noid) are handled, vianotificationHandler.Impact
Sol/Codex cannot use any ChatGPT connector through the plugin's runners:
codex:rescue) returnsuser rejected MCP tool callinstantly.codex mcp-server(driven from Claude Code) and plaincodex exechang on the unanswered elicitation (observed ~20+ min at 0% CPU).Repro
codex exec), ask the model to call any connector tool (a read-only one is enough).user rejected MCP tool call(rescue agent) or an indefinite hang (codex exec/codex mcp-server).Workaround
codex exec --dangerously-bypass-approvals-and-sandboxbypasses the approval handshake entirely and the connector call succeeds. Note:approval_policy = "never"in~/.codex/config.tomlalone is not sufficient — the connector elicitation still blocks. The interactivecodexTUI works because it answers the elicitation itself.Suggested fix
Implement
handleServerRequestto respond to approval / elicitation requests (auto-approve per the session'sapproval_policy, or surface them to the caller) instead of blanket-rejecting with-32601.Environment
codex@openai-codexv1.0.6 (marketplaceopenai/codex-plugin-cc)