Computer Use has no verified suspend/release/reacquire lifecycle across 1–5 minute compactions

Summary

When automatic context compaction begins during an active Codex Desktop Computer Use workflow, the stock Computer Use surface has no documented or observable operation to:

1. suspend/release the Computer Use session at compaction start,
2. prove that observation, screenshots, input, helper activity, and any Computer Use metering are inactive while compaction runs,
3. then safely reacquire Computer Use after compaction and resume the same UI task from a fresh target-state observation.

In repeated Windows Desktop use, I observe compaction—especially in screenshot-heavy Computer Use threads—lasting roughly 1–5 minutes. The agent can be instructed to stop making Computer Use calls during that interval, but “do not call the tool” is not the same as an explicit, verified release of the underlying Computer Use resource.

This report does not claim that every millisecond of the interval is independently billed. The bug is that neither the user nor the agent can guarantee or verify that the usage-heavy Computer Use surface has been released during a predictable long-running lifecycle event.

Environment

• Product: Codex Desktop on Windows
• OS: Windows 11 Pro x64
• Subscription: ChatGPT Pro
• Installed Computer Use skill/package: 26.901.41123
• Workload: long-running visible 3D-authoring workflow with short UI operations separated by code, image generation, tests, and automatic compaction

The installed Computer Use/Sky-facing documentation exposes window observation and input operations. I could not find an explicit session suspend, release, close-for-compaction, reacquire, or metering-state operation.

Observed behavior

A typical sequence is:

Computer Use is active on a visible application
→ automatic compaction begins
→ compaction runs for approximately 60–300 seconds
→ prompt-level instructions can stop new UI calls
→ no stock receipt proves the Computer Use session/lease was released
→ compaction finishes
→ the worker must infer when and how to resume Computer Use

The available PreCompact / PostCompact hook surface does not close this gap by itself:

• hook declarations do not prove the underlying Computer Use session was released;
• there is no durable receipt tying a Computer Use release to a specific compaction event;
• there is no visible active / suspended / released / reacquiring state;
• there is no stock guarantee that the post-compaction UI action is revalidated and resumed exactly once.

A local plugin can stop issuing screenshots and input, but it cannot honestly claim that it released a metered platform resource when the stock API exposes no such primitive.

Steps to reproduce

1. Start a long-running Codex Desktop task that uses Computer Use to operate a visible application.
2. Alternate brief UI operations with enough reasoning/tool/image work to reach automatic compaction.
3. Let automatic compaction begin while the task still owns an active Computer Use workflow.
4. Observe that compaction can remain in progress for roughly 1–5 minutes.
5. Inspect the stock Computer Use tool/skill surface and compaction hooks.
6. Try to explicitly suspend or release Computer Use at PreCompact, then verify it is inactive.
7. There is no documented operation or authoritative state/receipt for doing so.
8. After successful compaction, try to reacquire Computer Use, take a fresh target screenshot, validate application identity/state, and resume the pending UI action exactly once. This must currently be implemented as prompt/plugin convention rather than a stock lifecycle contract.

Expected behavior

Computer Use should be a just-in-time, compaction-aware resource with an explicit lifecycle:

ACTIVE
→ COMPACTION_STARTING
→ RELEASE_REQUESTED
→ RELEASED
→ COMPACTING_WITHOUT_COMPUTER_USE
→ COMPACTION_COMPLETED
→ WAITING_FOR_PREPARED_UI_ACTION
→ REACQUIRING
→ TARGET_REVALIDATED
→ ACTIVE

At compaction start

Codex should atomically:

• stop Computer Use observation, screenshot capture, polling, and input;
• release any controller-owned mouse buttons or keys;
• suspend or end the underlying Computer Use session/lease;
• preserve only a bounded resumable action checkpoint;
• emit a durable receipt linked to the compaction event.

During compaction

The following should be guaranteed:

Computer Use calls: 0
screenshots captured: 0
input events issued: 0
visual polling: 0
Computer Use metering state: released/inactive

After successful compaction

Codex should:

• continue the same task automatically rather than treating compaction as completion;
• keep Computer Use released until a concrete immediate UI action is prepared;
• reacquire it just in time;
• capture one fresh screenshot rather than trusting pre-compaction coordinates or imagery;
• revalidate target PID/window, document, modal state, geometry/DPI, focus, and recent operator input;
• resume the preserved action exactly once.

If compaction fails or state is uncertain

Computer Use should remain released. Codex should preserve the pending action and must not blindly replay a click, drag, save, export, close, or other consequential UI input.

Suggested observable contract

A compaction-linked receipt could expose fields such as:

{
  "compaction_event_id": "...",
  "computer_use_state_before": "active",
  "release_requested_at": "...",
  "release_confirmed_at": "...",
  "release_latency_ms": 0,
  "screenshots_during_compaction": 0,
  "input_events_during_compaction": 0,
  "metering_state_during_compaction": "inactive",
  "post_compaction_reacquired": true,
  "target_revalidated": true,
  "pending_action_resumed_count": 1
}

The exact schema can differ, but the system should let an operator answer: Was Computer Use actually released for this compaction, and did it resume safely afterward?

Why this matters

OpenAI’s current Codex usage documentation says usage depends on the model, task complexity, context, reasoning, speed, and tools, and that long-running tasks can use substantially more than short requests:

https://help.openai.com/en/articles/11369540

OpenAI has also publicly acknowledged compounding usage inefficiencies around images and repeated compaction. Tibo reported that retaining old images during compaction could make context large enough to compact again, and that fixing it reduced usage by about 10% for image-heavy users:

https://x.com/thsottiaux/status/2093801758665715784

The same post described other individually small background inefficiencies adding up at scale. Tibo later reported 25M active users:

https://x.com/thsottiaux/status/2094252447271366730

That population figure is used below only as a scale scenario. It is not a claim that every active user uses Computer Use or encounters this exact compaction boundary.

Potential fleet-scale impact if only 1% of 25M users are affected

One percent of 25 million users is 250,000 users.

Assume those 250,000 users each encounter one affected Computer Use compaction, and the avoidable unmanaged Computer Use interval is the observed 1–5 minutes:

Average unmanaged interval per affected compaction	Aggregate Computer Use-attached time for one cohort occurrence	Equivalent aggregate elapsed time
1 minute	250,000 minutes = 4,167 hours	173.6 days
3 minutes	750,000 minutes = 12,500 hours	520.8 days / 1.43 years
5 minutes	1,250,000 minutes = 20,833 hours	868.1 days / 2.38 years

That is the impact of one affected compaction per user in the 1% cohort. Because compaction is recurring, the annual exposure compounds quickly:

Frequency per affected user	1-minute interval	3-minute interval	5-minute interval
Once per month	50,000 hours/year	150,000 hours/year	250,000 hours/year
Once per week	216,667 hours/year	650,000 hours/year	1,083,333 hours/year
Three times per week	650,000 hours/year	1,950,000 hours/year	3,250,000 hours/year
Once per workday (260/year)	1,083,333 hours/year	3,250,000 hours/year	5,416,667 hours/year
Once per calendar day	1,520,833 hours/year	4,562,500 hours/year	7,604,167 hours/year

For perspective, the once-per-week case alone represents roughly 24.7–123.7 aggregate years of Computer Use-attached time per year across just 1% of the reported active-user population. The once-per-workday case represents roughly 123.7–618.3 aggregate years per year.

Even if an explicit release/reacquire lifecycle eliminates only 10% of that interval rather than all of it, the once-per-week scenario still avoids approximately 21,667–108,333 aggregate hours per year. At a 50% reduction, it avoids approximately 108,333–541,667 hours per year.

These figures describe potential aggregate resource exposure, not a claim that all of it is separately billed or that all 250,000 users have the same compaction frequency. OpenAI can replace the scenario assumptions with internal telemetry using:

affected_user_count
× affected_compactions_per_user
× average_computer_use_attached_minutes_during_compaction
÷ 60
= aggregate exposed hours

The direct time is only the first-order cost

The same lifecycle gap can create second-order and compounding costs:

• Computer Use allowance consumed during a period in which no useful UI action can complete;
• screenshot capture, encoding, upload, and visual-token processing;
• larger multimodal replacement histories;
• repeated compaction when image-bearing history remains too large;
• prompt-cache disruption after history is rewritten;
• app-server, Computer Use helper, browser, screen-capture, CPU, RAM, and GPU residency;
• extra post-compaction orientation turns and screenshots;
• duplicate or unsafe UI actions when stale coordinates are replayed;
• retries, app restarts, abandoned threads, manual recovery, support load, and user reset-token consumption.

Not every event will incur every cost. The point is that the same small lifecycle repair can remove several cost surfaces at once, and those savings compound with every repeated compaction.

Telemetry needed to quantify the real fleet impact

OpenAI can measure this precisely by recording, per compaction:

computer_use_state_at_compaction_start
computer_use_release_latency_ms
computer_use_attached_ms_during_compaction
computer_use_calls_during_compaction
screenshots_captured_during_compaction
screenshot_bytes_added_or_replayed
compaction_request_bytes_and_tokens
post_compaction_cache_hit_rate
post_compaction_orientation_calls
post_compaction_duplicate_action_count
helper_process_cpu_ram_gpu_time
retries_restarts_and_failed_resumes

The key target metric should be:

computer_use_attached_during_compaction_ms = 0

unless a narrowly documented platform requirement proves that some non-metered helper must remain alive.

Related issues — adjacent, but not duplicates

• #35458 and #33493: historical screenshots retained/re-persisted across compaction, causing context and storage amplification.
• #28633: missing auditable PreCompact / PostCompact hook receipts.
• #37420: Computer Use helper activity continuing while Computer Use is otherwise idle.
• #42702: browser/Computer Use automation replaying large context and consuming extreme usage.
• #25660: successful compaction interrupting execution instead of resuming automatically.

Those reports cover screenshot persistence, hook observability, idle helpers, context replay, or continuation. This issue is specifically about the missing atomic Computer Use release/reacquire contract at the compaction boundary.

Acceptance criteria

• PreCompact can release Computer Use through a first-class operation.
• Release is confirmed before compaction proceeds, or failure is surfaced explicitly.
• Computer Use’s active/metered state is observable.
• No screenshots, visual polling, or input occur while compaction runs.
• No controller-owned input remains held.
• PostCompact does not blindly restore stale visual state.
• The task continues automatically after successful compaction.
• Computer Use is reacquired only for a prepared UI action.
• A fresh target-state observation is required before input.
• The pending action is resumed at most once.
• Failed compaction leaves Computer Use released and the target application untouched.
• Regression coverage includes Windows/macOS, Desktop, screenshot-heavy workflows, long compactions, failed compactions, operator input during compaction, modal dialogs, target restart, and DPI/window changes.
• A fleet dashboard can report the affected-user count, exposed Computer Use hours, screenshot bytes, replayed tokens, and avoided cost before and after rollout.

Privacy

No private screenshots, rollout contents, local project paths, source assets, credentials, or application documents are included. Timestamped private evidence can be provided through an appropriate private support channel if maintainers need it.

Start by tracing the Computer Use surface and the PreCompact/PostCompact hook surface described in the issue. Determine how a compaction-linked release, confirmation, and post-compaction reacquisition could be observed; done means release is confirmed before compaction, inactivity is verifiable during it, and the target is revalidated before one safe resume.