Document and explicitly test response.steer with asynchronous tools

Category: Documentation and regression-test coverage request; no confirmed proxy regression is asserted.

Version: CLIProxyAPI v7.3.9 (61fdfc341b96178a8dcb53f2efc46cbc341d267c)

The experimental codex.response-steering option has full-duplex coverage already, including automatic successors, required tool input, and disconnect handling. Please document and explicitly cover its interaction with asynchronous function tools (async: true).

The configuration example refers to STEERING.md, but that file is absent from the v7.3.9 tree.

Existing relevant tests include:

• Full-duplex integration scenarios
• Duplex steering lifecycle
• Automatic successor metadata

Those steering/duplex test files do not contain an explicit async: true scenario. Ordinary tool-pending coverage is useful, but leaves the asynchronous-tool interaction implicit.

Suggested coverage

With codex.response-steering: true, a steering-capable model, and one downstream WebSocket connection:

1. Declare a synthetic asynchronous function tool and preserve async: true in both the request and returned call item.
2. Exercise steering during an output item and, separately, while a previously dispatched asynchronous tool is still running.
3. Confirm the steering frame reaches the same upstream connection before the parent response terminates, and the matching acceptance is forwarded.
4. Cover both valid parent outcomes: response.incomplete with reason steered, and normal response.completed.
5. Distinguish an automatic successor from a response explicitly started to submit required tool output. Return each saved result using its original call_id, without resending the accepted user update.
6. Verify inherited tool definitions on an automatic successor and the supported behavior when an asynchronous result becomes ready before the current response ends.

Documentation should explain when the client can submit an asynchronous result, when it must wait, and which events indicate that required input is blocking continuation. It should also distinguish client queueing from wire-level steering.

These are deterministic proxy-contract checks suitable for mock upstream tests. Model-generated duplicate calls with distinct call IDs and final-answer correctness are separate live-model observations, not by themselves evidence of proxy replay.

References:

• OpenAI mid-turn steering
• OpenAI async tool calling

Start with config.example.yaml and the existing steering tests in sdk/api/handlers/openai/openai_responses_steering_integration_test.go and internal/runtime/executor/codex_websockets_duplex_test.go. Add explicit async: true scenarios covering steering, successors, required tool output, and response outcomes, then document the behavior and the missing STEERING.md reference. Done means deterministic mock-upstream tests distinguish queueing from wire steering and explain when asynchronous results may be submitted.