Codex Desktop usage drained unexpectedly during a short browser-extension workflow

Summary

Codex Desktop token/usage allowance appeared to drain unexpectedly quickly while running a short local thread that used the bundled Chrome extension runtime. The visible workflow was small: two turns, roughly one completed 5.6-minute turn plus one resumed active turn, with browser-profile attachment, page inspection, DOM snapshots, screenshots, locator checks, one text-field fill, and one button click.

The report below intentionally excludes the private task domain, site name, account names, profile names, local paths, page URL, private entity IDs, page content, and user business context. Please use the thread ID for internal investigation of the raw telemetry.

Thread Details

• Codex thread ID: 019f1706-0c6d-7572-b4d2-10e7553cf9a6
• Codex Desktop host: local
• Thread status when inspected: active
• Timezone: Asia/Jakarta
• Thread started: 2026-06-30 12:35:00 +07:00
• First turn completed: 2026-06-30 12:40:51 +07:00
• First turn duration: 337,973 ms
• Second turn started: 2026-06-30 12:42:26 +07:00
• Last observed thread update: 2026-06-30 12:44:44 +07:00
• Workflow type: private authenticated browser automation through the Codex Chrome extension runtime

Expected Behavior

Usage should roughly correspond to the small visible workload in the thread, especially after recent public communications that usage had been reset. A short browser-extension workflow should not rapidly consume a large portion of the available allowance unless there is a clear accounting reason visible to the user.

Actual Behavior

The usage allowance dropped much faster than expected during or immediately after this thread. From the user-visible perspective, the work did not involve a large codebase, bulk file processing, long document ingestion, multi-file generation, or a long-running analysis task.

Technical Timeline

1. User started a local Codex Desktop thread.
2. Codex initialized or reused the local node_repl runtime.
3. Codex loaded the bundled Chrome extension browser client from the local Codex plugin cache.
4. Codex listed available browser/profile entries from the Chrome extension runtime.
5. Codex selected an existing browser profile by metadata.profileName.
6. Codex opened or claimed one browser tab in that existing profile.
7. Codex navigated to a private authenticated web page. The URL and site/domain are redacted.
8. Codex waited for page load and inspected page state through DOM snapshots.
9. Codex captured screenshots for visual verification.
10. Codex inspected buttons, form fields, card/list structures, and page text through Playwright/DOM calls.
11. Codex stopped before making a state-changing action and asked for confirmation.
12. User confirmed.
13. Codex resumed the same browser/profile workflow.
14. Codex reclaimed or reused the existing tab.
15. Codex revalidated that the private account/page context matched the expected one. The account identity is redacted.
16. Codex checked locators and form state.
17. Codex performed one text-field fill and one submit/button click in the private web app.
18. Codex observed a success state and began inspecting the resulting page state.

Observed Tool Activity

The inspected thread contained approximately:

• 21 total node_repl tool calls
• 20 completed node_repl tool calls
• 1 failed node_repl tool call
• 2 screenshot/visual capture calls
• Multiple DOM snapshot and Playwright locator inspection calls
• Browser/profile listing and tab-claiming calls
• One text-field fill
• One button click

No tool outputs are included here because they may contain private page data. Internally, the thread ID should provide access to the raw telemetry needed to verify exact token accounting.

Why This Looks Unexpected

The token/usage drop felt disproportionate to:

• The short elapsed time of the thread.
• The small number of user turns.
• The limited browser automation scope.
• The absence of large local repository analysis or document ingestion.
• The fact that recent usage resets had reportedly occurred.

Possible Investigation Areas

Please check whether any of the following contributed to unexpectedly high usage:

• DOM snapshots or screenshot metadata being counted much more heavily than expected.
• Tool call arguments/results being retained or replayed across turns in a way that compounds usage.
• Active/in-progress thread state continuing to consume usage after the visible workflow appears paused.
• Browser-extension setup/listing calls being double-counted.
• Hidden context from previous local sessions, thread summaries, or plugin/tool metadata being included unexpectedly.
• Usage reset state not being applied consistently to this account/session.
• UI usage meter lag, double-counting, or displaying a different accounting window from what the user expects.

Requested Help

Could the team investigate token accounting for thread 019f1706-0c6d-7572-b4d2-10e7553cf9a6 and confirm:

• Whether the recorded usage for this thread is expected.
• Which calls or context chunks contributed most to usage.
• Whether recent usage resets were correctly applied.
• Whether this was actual consumption or a UI/reporting issue.
• Whether browser-extension workflows can expose clearer per-turn or per-tool usage diagnostics.

Suggested Routing

This likely needs input from multiple areas:

• Codex Desktop app / local thread runtime
• Usage, quota, or token-accounting systems
• Browser extension and node_repl tooling
• Usage-meter UI/reporting

Sanitization Notes

The following details were intentionally removed from this public report:

• Private task/domain description
• Website/service name
• Full URL
• Account/business names
• Chrome profile names
• Local Windows username and filesystem paths
• Private entity IDs
• Private page text
• Generated text entered into the private web app
• Screenshots and raw DOM/tool outputs

Only technical execution metadata is included.