Windows Computer Use can reacquire foreground input after node_repl resets without a revocable single-controller lease

Start by tracing the node_repl/js_reset flow and the @oai/sky Windows transport lifecycle, including where foreground input is acquired and stopped. Verify the current-turn grant, single-controller ownership, revocation events, fresh-observation requirement, and rejection of competing input mechanisms; done means reset, interruption, stop, timeout, focus loss, and transport failure prevent silent reacquisition.

What version of the Codex App are you using?

Codex Desktop 26.730.8199.0; bundled Computer Use plugin 26.730.61639.

What platform is your computer?

Windows 11 x64.

What issue are you seeing?

On Windows, a Computer Use task can repeatedly reset node_repl, import @oai/sky again, create another transport, and continue issuing foreground input without a single revocable controller lifecycle.

During the observed run, desktop redraw and window switching became severely delayed and the desktop sometimes appeared frozen. Pressing Escape sometimes released visible updates. Explicitly instructing the task to stop caused it to close the transport and stop foreground input. Restarting Windows later cleared the accumulated state, but reboot is not a fix.

This report is about the Computer Use transport lifecycle and foreground-input boundary, not the GPU/display driver.

What steps can reproduce the bug?

1. Start a Windows Computer Use task for a desktop application.
2. Import @oai/sky and create/use its Windows transport.
3. Call node_repl/js_reset.
4. Import @oai/sky again and reacquire the transport without a new user grant.
5. Repeat the reset/reacquisition cycle while issuing UI actions.
6. Mix fresh observations with repeated fixed-coordinate input or another Windows UI-input mechanism.
7. Observe that foreground input can continue across resets without one auditable owner or revocation boundary.

In the observed case, one task repeated this cycle several times over approximately eight minutes. Repository instructions were not an enforcement boundary because the runtime still allowed direct transport recreation.

What is the expected behavior?

• A current-turn grant naming the app and action should be required before @oai/sky creates a Windows input transport.
• One foreground maintenance window should own exactly one persistent node_repl / Sky transport and one controller.
• js_reset should close and revoke the existing transport and must not permit silent reacquisition.
• User input, Escape/stop, turn interruption, unknown focus, timeout, or transport failure should revoke the grant and prevent automatic reacquisition.
• The runtime should reject competing foreground-input mechanisms in the same turn.
• Input should be derived from a fresh returned-window observation; stale coordinates should not remain valid after state changes.
• The lifecycle should expose auditable grant, transport-start, action, stop, and revocation events.

Additional information

Local repository rules can tell an agent not to reset/recreate transports or mix input methods, but they cannot enforce this boundary when the current plugin imports @oai/sky directly. The boundary needs to exist in the runtime.

Related but distinct:

• #37013: stale node_repl execution context across Computer Use calls
• #37180: missing approval prompt and node_repl exec context not found

Those reports cover nearby transport/context failures, but not revocation and repeated foreground-input reacquisition after js_reset.