Best possible solution:

Apply the no-prompt-timeout override to the AcpxRuntime.startTurn delegate path as well, while keeping the constructor timeout for startup/control operations and covering the registered-backend startTurn path in tests.

Do we have a high-confidence way to reproduce the issue?

Yes from source inspection: acpx 0.7.0 applies input.timeoutMs ?? options.timeoutMs to prompt turns and can complete after partial output, while OpenClaw routes managed acpx turns through startTurn. I did not run a live long-running adapter repro in this read-only pass.

Is this the best way to solve the issue?

No: changing only runTurn is not the best fix because the manager uses startTurn when available. The narrow maintainable fix is to pass timeoutMs: 0 into the delegate startTurn call and test that path.

Full review comments:

• [P1] Disable the startTurn timeout path too — extensions/acpx/src/runtime.ts:1038
  The new timeout override only wraps delegate.runTurn(...), but OpenClaw-managed acpx turns normally go through service.startTurn and consumeAcpTurnStream, which call AcpxRuntime.startTurn. That method still forwards delegate.startTurn(input), so acpx 0.7.0 falls back to the constructor timeout and can still synthesize a completed turn after partial output. Please pass the no-timeout override through the startTurn delegate path and cover that path in the regression test.
  Confidence: 0.93

Overall correctness: patch is incorrect
Overall confidence: 0.9

Acceptance criteria:

• node scripts/run-vitest.mjs extensions/acpx/src/runtime.test.ts -t "disables delegate prompt timeout"
• node scripts/run-vitest.mjs extensions/acpx/src/service.test.ts
• node scripts/run-vitest.mjs src/acp/control-plane/manager.test.ts -t "times out a hung persistent turn after partial progress"
• git diff --check

What I checked:

• OpenClaw uses startTurn when available: consumeAcpTurnStream prefers runtime.startTurn(params.turn) and only falls back to runtime.runTurn, so the acpx backend normally follows the startTurn path for managed turns. (src/acp/control-plane/manager.turn-stream.ts:115, 327b0b8734d5)
• Registered acpx backend exposes startTurn: The lazy acpx service registers a startTurn method and routes manager calls through startRuntimeTurn, so disabling only runTurn does not cover the main runtime path. (extensions/acpx/src/service.ts:256, 327b0b8734d5)
• startTurn still forwards the original input: Current AcpxRuntime.startTurn delegates with delegate.startTurn(input); the PR patch shown in the supplied context changes delegate.runTurn but not this startTurn delegate call. (extensions/acpx/src/runtime.ts:1038, 327b0b8734d5)
• acpx timeout contract: The published acpx 0.7.0 runtime type includes AcpRuntimeTurnInput.timeoutMs; its runtime implementation uses input.timeoutMs ?? this.options.timeoutMs for prompt turns and treats a timeout after an observed agent reply as a completed turn, which is the behavior this PR is trying to suppress.
• Recent feature history: Commit 635b947 introduced the current startTurn terminal-result path and related ACP/acpx tests, making it the relevant current-main provenance for this surface. (extensions/acpx/src/runtime.ts:1026, 635b947e32e0)

Likely related people:

• steipete: Recent current-main history shows Peter Steinberger introduced the startTurn terminal-result handling and related ACP/acpx tests in commit 635b947; blame also points to that commit for AcpxRuntime.startTurn. (role: recent ACP/acpx feature owner; confidence: high; commits: 635b947e32e0; files: extensions/acpx/src/runtime.ts, extensions/acpx/src/service.ts, src/acp/control-plane/manager.turn-stream.ts)

Remaining risk / open question:

• No live long-running ACP/Codex adapter run was executed during this read-only review, so the verdict is based on source and acpx package-contract proof rather than live runtime proof.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 327b0b8734d5.