request_user_input is aborted immediately when autoResolutionMs is omitted

[julianmesa-gitkraken]

Summary

When Codex sends a request_user_input request without autoResolutionMs, codex-acp aborts the elicitation immediately and returns an empty answers object before the client can render the form.

This reproduces in @agentclientprotocol/codex-acp 1.1.4 and is still present in the latest published 1.1.7.

Reproduction

Launch a Codex session through codex-acp and send a tool/requestUserInput request whose params omit autoResolutionMs:

{"questions":[{"header":"Test","id":"test_request_user_input","question":"Continue?","options":[{"label":"Accept","description":"Continue"},{"label":"Cancel","description":"Stop"}]}]}

Expected: the elicitation request reaches the client and waits for the user response.

Actual: the request is aborted immediately, no form is shown, and the agent receives {"answers":{}}.

Root cause

In dist/index.js, requestUserInputElicitation currently uses a strict null check:

if (params.autoResolutionMs === null) {
  return await this.connection.request(...)
}

When the field is omitted, its value is undefined, so the condition is false. The timeout path then evaluates undefined ?? 0 and schedules resolveWithoutInput with a zero-millisecond timeout. The abort wins the Promise.race on the next tick.

Proposed fix

Treat both null and undefined as no auto-resolution:

if (params.autoResolutionMs == null) {

Equivalent: (params.autoResolutionMs ?? null) === null.

This preserves the existing timeout behavior when an explicit numeric autoResolutionMs is provided, while making the omitted field follow the normal blocking elicitation path.

I have verified the one-character change locally by carrying it as a pnpm patch against 1.1.4.

Additional context

autoResolutionMs is optional in the wrapper input path, and Codex sends request_user_input without it in normal plan-mode flows. An absent value should therefore mean no auto-resolution, not immediate auto-resolution.

[2409324124]

Confirmed and fixed in #408.

Reproduction

The bug is present on main (1.4.0). requestUserInputElicitation gates the blocking path on params.autoResolutionMs === null (src/CodexElicitationHandler.ts:393); when Codex omits the field it arrives as undefined, so undefined ?? 0 schedules resolveWithoutInput with a 0ms timeout and the abort wins Promise.race on the next tick.

Added a regression test in src/__tests__/CodexACPAgent/elicitation-events.test.ts that sends request_user_input with autoResolutionMs omitted while the client answers 200ms later:

• current code: returns {answers:{}} in ~11ms (bug reproduced, matches your report exactly)
• with the one-line fix (== null): waits ~200ms and returns the client's answers

Fix

if (params.autoResolutionMs == null) treats both null and undefined as no auto-resolution; explicit numeric timeout behavior is unchanged. Full suite: 435 passed, 28 skipped, npm run typecheck clean.

Note: this is covered by a mock-fixture unit test rather than an e2e test because request_user_input is emitted by a real Codex session during interactive flows — a live-model e2e cannot deterministically reproduce the omitted-field shape.