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.
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:
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:
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.