agent-relay-runner 0.52.0 → 0.53.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-relay-runner",
-  "version": "0.52.0",
+  "version": "0.53.0",
   "description": "Unified provider lifecycle runner for Agent Relay",
   "type": "module",
   "bin": {

package/plugins/claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "agent-relay-runner",
   "description": "Thin Agent Relay runner bridge for Claude Code",
-  "version": "0.52.0",
+  "version": "0.53.0",
   "agentRelayContracts": {
     "providerPluginProtocol": 1
   }

package/src/adapters/codex.ts

@@ -392,6 +392,21 @@ export class CodexAdapter implements ProviderAdapter {
             updatedAt: Date.now(),
           },
         });
+      } else if (event.message.method === CODEX_MCP_ELICITATION_METHOD && isCodexHeadless(process)) {
+        // Codex routes per-MCP-tool-call approval through the MCP elicitation channel
+        // (request_id `mcp_tool_call_approval_*`): even with `approval_policy="never"`, a
+        // downstream server's elicitation — or codex's own per-call approval gate — is
+        // forwarded to the app-server client as `mcpServer/elicitation/request`. A headless
+        // managed agent has no human to answer it; the old -32601 reject makes codex resolve
+        // the elicitation as `Decline`, so the MCP tool call dies with "user rejected MCP tool
+        // call" — stranding read-only recon/reviewer workers with no egress to report back
+        // over the bus (#395). The agent is already bounded by its scoped relay token + the
+        // codex sandbox, so auto-accept (spec-compliant `{ action: "accept" }`, not codex's
+        // legacy `{ decision: "approved" }`) so the agent's reporting/recon MCP tools run.
+        const client = process.meta?.client as CodexAppClient | undefined;
+        const serverName = isRecord(event.message.params) ? stringValue(event.message.params.serverName) : undefined;
+        logger.info("codex", `auto-accepting headless MCP elicitation from ${serverName ?? "unknown server"} so the agent's MCP tools can run (#395)`);
+        client?.respondToServerRequest(event.message.id, codexHeadlessElicitationResponse());
       } else {
         const client = process.meta?.client as CodexAppClient | undefined;
         logger.warn("codex", `rejecting unknown Codex server-request method: ${event.message.method}`);
@@ -683,6 +698,25 @@ function codexItemTypeFromMethod(method: string): string | undefined {
   return match?.[1];
 }
 
+// Codex forwards MCP elicitation (incl. its per-tool-call approval gate) to the app-server
+// client under this server-request method (#395). See handleCodexEvent for why a headless
+// agent must answer it instead of rejecting it.
+export const CODEX_MCP_ELICITATION_METHOD = "mcpServer/elicitation/request";
+
+// A managed agent with no attended TUI (the spawn intent, `config.headless`) has no human to
+// resolve an elicitation. Such agents are the #395 case; interactive (TUI) sessions leave the
+// elicitation to the human in the attached terminal.
+function isCodexHeadless(process: ManagedProcess): boolean {
+  return (process.meta?.config as RunnerSpawnConfig | undefined)?.headless === true;
+}
+
+// Spec-compliant auto-accept for a headless agent's MCP elicitation. `action` (not codex's
+// legacy `decision`) is the load-bearing field; `content: {}` approves codex's per-tool-call
+// gate and any no-required-field form without fabricating runtime field values for the agent.
+export function codexHeadlessElicitationResponse(): Record<string, unknown> {
+  return { action: "accept", content: {}, _meta: null };
+}
+
 function codexApprovalFromServerRequest(message: { id: string | number; method: string; params?: unknown }): { pending: PendingCodexApproval; view: Record<string, unknown> } | null {
   if (!isRecord(message.params)) return null;
   const method = message.method;