[Bug]: ACP silently drops a reasoning/config option when set_config_option fails transiently, and never retries it #33117

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server (ACP provider adapter, packages/provider-acp)

Steps to reproduce

Deterministic repro using the scripted ACP protocol replay in AcpRegistryAdapterV2.test.ts:

1. Open an ACP session whose model config option is default. The agent does not advertise a thinking option yet.
2. Start a turn with model named and options thinking=high, plus an option the session never advertises (unavailable=x).
3. The agent accepts session/set_config_option model=named and now advertises thinking (low/high).
4. T3 sends session/set_config_option thinking=high. The agent answers with a JSON-RPC error that is not invalid-params, for example -32603 internal error (a transient failure or a dropped request).
5. Start another turn with the same selection.

Expected behavior

Only invalid-params (-32602), which means the agent refused the value, should be logged and skipped. Any other request error should fail session configuration. That leaves the selection unapplied, so the next turn re-sends thinking=high. configureSession already handles the model write this way ("Invalid params is the agent refusing the value… Other failures, such as sign-in or a lost connection, keep their own error"). Options never advertised by the session should still be skipped.

Actual behavior

In packages/provider-acp/src/server/adapter.ts, the option loop in configureSession catches every AcpRequestError from setConfigOption, logs "ACP session rejected a configuration option value" and continues. The turn starts on the agent's current thinking level, not the requested high. activeSelection is then set to the requested selection, so later turns treat it as applied and never retry it. The user sees the requested reasoning level in the UI while the agent runs on another one, with nothing but a server log warning.

Impact

Minor bug or occasional failure. It only happens when an option write fails for a reason other than refusal, but then the wrong setting persists for the rest of the session.

Version or commit

main at 3fa57b9 (the code is unchanged there).

Environment

Linux, Node 26.12.1. Reproduced with the repository's scripted ACP replay test harness, not a real provider.

Logs or stack traces

On unmodified main, a replay test of the scenario above fails at step 4, because the first turn succeeds even though the option write failed:

× retries a failed option after model activation and skips unavailable stored options
AssertionError: expected 'Success' to equal 'Failure'

Workaround

Re-select a different value and then the desired one, or restart the session.

Related

#19754 restructures the same loop but keeps swallowing all request errors. #14723 fixed the equivalent retry for model switches.