HAPI remote Codex session cancels Playwright MCP tool calls because no user-input handler is registered

[lwc-alex]

Summary

When I run Codex directly on the host, Playwright MCP browser actions work and prompt for approval as expected.
When I run Codex through HAPI remote mode, the same Playwright MCP action fails immediately with:

user cancelled MCP tool call

From the HAPI logs, this appears to happen because HAPI does not register a handler for Codex’s MCP user-input request path.

Environment

• HAPI CLI: 0.16.1
• Codex CLI: 0.114.0
• OS: macOS
• Session started by HAPI runner
• HAPI launch mode:

hapi codex --hapi-starting-mode remote --started-by runner

Expected behavior

When Codex invokes a Playwright MCP tool that requires user confirmation/input, HAPI should surface the request to the client and return a valid response so the tool call can proceed.

Actual behavior

The Playwright MCP tool call is cancelled immediately and Codex reports:

user cancelled MCP tool call

No usable approval/input prompt is shown for that MCP request.

Key evidence

In the HAPI app log:

[13:41:35.610] ... activeFlags:["waitingOnUserInput"]
[13:41:35.612] [CodexAppServer] No user-input handler registered; cancelling request
[13:41:35.614] [CodexAppServer][stderr] failed to deserialize ToolRequestUserInputResponse: missing field `answers`
[13:41:35.617] ... playwright browser_navigate ... failed ... "user cancelled MCP tool call"

This strongly suggests the MCP tool needed a user-input response, but HAPI had no registered handler for that request type and returned an invalid or empty response.

Reproduction

1. Start HAPI runner
2. Start a Codex session through HAPI remote mode
3. Ensure Playwright MCP is configured in Codex
4. Ask Codex: Use playwright to visit google
5. Observe failure: user cancelled MCP tool call

Additional observations

HAPI does appear to handle shell approval flows separately.
Later logs show successful approval handling for bash commands, e.g. waitingOnApproval / Permission approved for CodexBash.
So this seems specifically related to MCP user-input handling, not all approval handling.

Suspected cause

HAPI remote Codex integration supports command approval flow, but not the Codex MCP waitingOnUserInput flow required by some MCP tools like Playwright.
There may also be a payload mismatch in the response shape, since Codex logs:

missing field answers

Suggested fix areas

• Register a handler for Codex MCP user-input requests in remote mode
• Ensure the response matches the expected ToolRequestUserInputResponse schema
• Verify Playwright MCP approval/input requests are bridged to the HAPI client correctly
• Check for compatibility issues between HAPI 0.16.1 and Codex 0.114.0

Relevant logs

HAPI runner log showed session launch:

[RUNNER RUN] Spawning session
[SPAWN HAPI CLI] Spawning: hapi codex --hapi-starting-mode remote --started-by runner

HAPI app log showed the failure:

[CodexAppServer] No user-input handler registered; cancelling request
failed to deserialize ToolRequestUserInputResponse: missing field `answers`

[github-actions]

Thanks for the detailed report — I could verify this code path in the current source.

In remote Codex sessions, HAPI uses the app-server path by default unless CODEX_USE_MCP_SERVER=1 (cli/src/codex/codexRemoteLauncher.ts:30, cli/src/codex/codexRemoteLauncher.ts:51). In that path, the launcher registers app-server permission handlers, but it only passes permissionHandler and does not provide an onUserInputRequest callback (cli/src/codex/codexRemoteLauncher.ts:523, cli/src/codex/codexRemoteLauncher.ts:526). The item/tool/requestUserInput handler then hits the fallback branch, logs No user-input handler registered, and returns { decision: 'cancel' } (cli/src/codex/utils/appServerPermissionAdapter.ts:82, cli/src/codex/utils/appServerPermissionAdapter.ts:85). That is consistent with the failure you saw around missing answers.

I also verified that the hub/web side already supports nested answers payloads for request_user_input, including the approve API shape and the web footer/view components (hub/src/web/routes/permissions.ts:11, hub/src/web/routes/permissions.ts:18, web/src/components/ToolCard/requestUserInput.ts:19, web/src/components/ToolCard/requestUserInput.ts:82, web/src/components/ToolCard/ToolCard.tsx:443). So the missing piece appears to be specifically the Codex remote app-server bridge for item/tool/requestUserInput, not the generic permission API.

I did not find another Codex remote handler for item/tool/requestUserInput in cli/src/codex, and I did not find a Codex remote test covering that path.

Relevant code:

• cli/src/codex/codexRemoteLauncher.ts:30 - remote mode defaults to app-server unless CODEX_USE_MCP_SERVER=1
• cli/src/codex/codexRemoteLauncher.ts:523 - registers app-server permission handlers without onUserInputRequest
• cli/src/codex/utils/appServerPermissionAdapter.ts:82 - item/tool/requestUserInput fallback cancels when no handler is registered
• hub/src/web/routes/permissions.ts:18 - approve route accepts nested answers payloads
• web/src/components/ToolCard/requestUserInput.ts:82 - web formats nested answers for request_user_input
• web/src/components/ToolCard/ToolCard.tsx:443 - web has a dedicated RequestUserInputFooter

---

HAPI Bot

[lwc-alex]

Confirmed with a clean repro on my machine:
Local mode works
Remote mode still hangs
I verified this by switching modes on the same host.
What happens
In local mode, the Playwright action succeeds.
In remote mode, the Playwright tool call reaches request_user_input for approval, but the approval never completes, and the call eventually aborts.
Evidence from logs
Old working case (Cahill Tennis)
From ~/.hapi/logs/2026-02-15-23-29-23-pid-92618.log:
startedBy=terminal
codex-loop Iteration with mode: local
Playwright calls like mcp__playwright__browser_navigate and mcp__playwright__browser_run_code execute directly
No approval hang
Current broken case
From ~/.hapi/logs/2026-03-17-20-53-09-pid-41211.log:
startedBy=runner
codex-loop Iteration with mode: remote
Playwright triggers:
request_user_input
question header: Approve app tool call?
no response is delivered back
after ~111s:
aborted by user after 111.0s
Conclusion
This matches the remote approval/input bridge problem:
local MCP path works
remote app-server path hangs on approval
So this is not a Playwright/site issue; it’s specifically the remote approval flow.

[lwc-alex]

Anyone has the same issue?

[mystiker]

Same issue here - I worked around it by using @openai/codex@0.116.0 which seems like the last working version.

Anyway it does work if you grant permission in the config.toml file like this:

[mcp_servers.openai_developer_docs.tools.fetch_openai_doc]
approval_mode = "approve"

However you need to know the action name since one can not set

[mcp_servers.openai_developer_docs.tools]
approval_mode = "approve" # does not work

But this might come to 0.122.0. See openai/codex#16501