Codex Desktop lacks stable local HTML render/export path in projectless threads

Summary

In Codex Desktop on Windows, a projectless thread could create a local HTML/CSS deliverable but could not use a stable Codex browser/local preview path to render or export it as a PNG. The workflow degraded into shell-based browser discovery and failed to produce the image artifact.

Short version: Codex successfully built the cake, decorated the cake, put the cake in outputs, then discovered it had no reliable way to photograph the cake. It then wandered around the Windows filesystem looking for Chrome/Edge like a very expensive flashlight.

This happened during a normal deliverable workflow:

1. generate a deterministic HTML infographic/report
2. preview/render it locally
3. export/capture a PNG
4. return the final artifact

Step 1 succeeded. Steps 2-3 failed because no reliable Codex browser/render/screenshot capability was available in the thread, and external browser fallback discovery also failed.

The user-facing failure was not "Codex cannot write HTML." It can. The failure was the last-mile visual artifact path: local HTML -> rendered preview -> screenshot/export.

Environment

• Product: Codex Desktop
• Session originator: Codex Desktop
• Session source: vscode
• Codex CLI version recorded in session metadata: 0.142.5
• Session id: 019f213d-e8d6-7fb2-aabd-ec029c3fcb76
• Model provider: openai
• OS: Windows
• Shell: Windows PowerShell 5.1.19041.6456
• Node: v22.19.0
• npm: 10.9.3
• GitHub CLI: gh version 2.93.0 (2026-05-27)
• Thread type: projectless Codex thread
• Workspace cwd:
• C:\Users\Lawrence\Documents\Codex\2026-07-01\are
• Output artifact created successfully:
• C:\Users\Lawrence\Documents\Codex\2026-07-01\are\outputs\codex-technical-breakdown.html
• file size: 10666 bytes

Session metadata was read from:

C:\Users\Lawrence\.codex\sessions\2026\07\01\rollout-2026-07-01T22-12-13-019f213d-e8d6-7fb2-aabd-ec029c3fcb76.jsonl

Reproduction

1. In a projectless Codex Desktop thread on Windows, ask Codex to generate a technical infographic/report from local Codex session history.
2. Codex writes a local HTML/CSS deliverable under the workspace outputs folder.
3. Ask/expect Codex to export the local HTML deliverable to a PNG.
4. Codex attempts to find a browser/render/screenshot path.

User-visible timeline

All times below are from the local session log for 019f213d-e8d6-7fb2-aabd-ec029c3fcb76.

2026-07-02T05:12:32Z  User asks for an infographic from Codex conversation/work history.
2026-07-02T05:13:04Z  User clarifies: use everything Codex has done since installation.
2026-07-02T05:15:34Z  Image generation completes for an initial poster-style infographic.
2026-07-02T05:16:59Z  User rejects it as not technical enough.
2026-07-02T05:17:39Z  Codex classifies local session history into technical categories.
2026-07-02T05:18:39Z  Codex writes deterministic HTML/CSS technical breakdown.
2026-07-02T05:18:46Z  Codex attempts to export HTML to PNG.
2026-07-02T05:19:00Z  Codex reports Node is available but no browser binary was found.
2026-07-02T05:19:10Z  Codex returns HTML only, not PNG.
2026-07-02T05:20:13Z  User: "wow codex browser is so broken. send a bug report to devs"
2026-07-02T05:20:30Z  Codex incorrectly stops at "no direct feedback tool" and offers a pasteable report.
2026-07-02T05:20:51Z  User points out GitHub via gh is available.
2026-07-02T05:21:33Z  Codex files this issue via gh.
2026-07-02T05:23:11Z  User asks for more debug info.
2026-07-02T05:24:27Z  Codex updates issue with concrete environment/debug details.

There are two bugs or product gaps in that timeline:

1. The main bug: the Codex Desktop local browser/render/export path was not available or not callable in this projectless context.
2. The secondary agent-behavior bug: Codex initially failed to use the obvious gh path for reporting even though GitHub CLI was authenticated and available. The user had to point at the sign that said "GitHub." Not ideal.

Expected behavior

Codex Desktop should expose a stable local browser/render/screenshot tool in this context, or provide an equivalent built-in export path for local HTML files.

Expected loop:

1. Write local HTML/CSS file.
2. Render the local file, ideally without relying on system Chrome/Edge installation discovery.
3. Capture/export PNG or PDF.
4. Return the final artifact path.

Actual behavior

No usable Codex browser automation/export path was available to the agent in the thread. The agent then attempted shell fallbacks to discover external browser binaries, but those also failed. The final deliverable was HTML only, despite the user wanting an infographic-style artifact.

Tooling checks performed

Codex/browser capability discovery

The agent previously attempted tool discovery for bug-report/feedback routing. The available dynamically exposed tools after that search included GitHub, Codex thread-management tools, and multi-agent tools, but no usable local browser render/screenshot/export tool for this workflow.

The session did have an available skill named browser:control-in-app-browser, but the relevant browser-control tools were not exposed as callable tools in the active turn. From the agent's perspective, this left no stable app-native way to open a local file and screenshot it.

That matters because this was exactly the kind of task where the app-native browser should be the reliable path. A local HTML report is not exotic. It is the "hello world" of visual deliverables with deterministic text.

Shell browser discovery

Command:

Get-Command msedge,chrome,chromium,chromium-browser,playwright -ErrorAction SilentlyContinue |
  Select-Object Name,Source,Version

Observed result:

<no output>

Command:

$paths = @(
  "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
  "$env:ProgramFiles(x86)\Google\Chrome\Application\chrome.exe",
  "$env:ProgramFiles\Microsoft\Edge\Application\msedge.exe",
  "$env:ProgramFiles(x86)\Microsoft\Edge\Application\msedge.exe",
  "$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe",
  "$env:LOCALAPPDATA\Microsoft\Edge\Application\msedge.exe"
)
foreach ($p in $paths) {
  [pscustomobject]@{ Path=$p; Exists=(Test-Path -LiteralPath $p) }
}

Observed result:

Path                                                                  Exists
----                                                                  ------
C:\Program Files\Google\Chrome\Application\chrome.exe                  False
C:\Program Files(x86)\Google\Chrome\Application\chrome.exe             False
C:\Program Files\Microsoft\Edge\Application\msedge.exe                 False
C:\Program Files(x86)\Microsoft\Edge\Application\msedge.exe            False
C:\Users\Lawrence\AppData\Local\Google\Chrome\Application\chrome.exe   False
C:\Users\Lawrence\AppData\Local\Microsoft\Edge\Application\msedge.exe  False

Runtime/tool versions

PowerShell:

PSVersion: 5.1.19041.6456
PSEdition: Desktop
BuildVersion: 10.0.19041.6456

Node/npm/gh:

node v22.19.0
npm 10.9.3
gh version 2.93.0 (2026-05-27)

Codex session metadata:

session_id: 019f213d-e8d6-7fb2-aabd-ec029c3fcb76
cwd: C:\Users\Lawrence\Documents\Codex\2026-07-01\are
originator: Codex Desktop
cli_version: 0.142.5
source: vscode
model_provider: openai

Why this is likely a Codex Desktop/browser capability issue

The agent successfully generated the deterministic HTML deliverable. The failure was specifically at the local render/export step.

For Codex Desktop, this should not depend on whether the user's system has a discoverable Chrome/Edge install on PATH or in common install locations. If the app already has an embedded/in-app browser, browser plugin, or browser session machinery, the agent needs a reliable callable surface for:

• opening file:// or workspace-local HTML
• waiting for layout
• capturing a screenshot at a specified viewport
• saving PNG/PDF into the workspace

If that surface is intentionally unavailable in projectless threads, Codex should report that clearly so the agent can stop instead of attempting brittle shell fallbacks.

Right now the agent experience is ambiguous: it can see that browser-related skill guidance exists, but it cannot actually call the corresponding browser controls. That creates the worst middle state: enough signal to try, not enough tool surface to finish.

Impact

This breaks a common high-value local deliverable workflow:

• create a deterministic HTML/CSS report, infographic, diagram, or dashboard
• preview it locally
• export a shareable PNG/PDF

It also produces a poor user experience because the underlying artifact generation succeeds, but Codex cannot complete the final export step.

In this particular thread, the user saw three separate papercuts stack up:

• the first generated infographic was too generic
• the corrected technical HTML artifact could not be exported to PNG
• the first bug-report response failed to use gh until the user explicitly corrected it

Individually, each is survivable. Together, they are how a simple "make me a technical breakdown" task turns into a debugging invoice.

Account credit / token reimbursement request

The user also requests that the tokens spent generating and debugging this broken browser/export path be credited back to their account.

The blunt customer version: the user is paying to use Codex, hit a basic product workflow that should work out of the box, then had to spend a large amount of additional paid model usage proving that the product path was broken. This is not speculative "I did not like the answer" usage. This is usage caused by a missing or inaccessible first-party capability in Codex Desktop.

The user expectation is straightforward: if a paid product cannot complete a basic local browser/export workflow, the customer should not be charged for the cascading debug session required to identify and report that failure.

Local session token telemetry shows the following cumulative usage checkpoints for the affected session:

Checkpoint                         total_tokens  input_tokens  cached_input  output_tokens  reasoning_output
After initial poster               381,297       377,870       285,952       3,427          936
After technical HTML/export fail   775,649       766,089       617,344       9,560          2,093
After first GitHub issue filing    1,219,906     1,208,209     1,034,752     11,697         2,545
After expanded debug update        1,698,456     1,683,371     1,495,168     15,085         2,700

The latest local telemetry point was 2026-07-02T05:24:38.540Z:

total_tokens: 1,698,456
input_tokens: 1,683,371
cached_input_tokens: 1,495,168
output_tokens: 15,085
reasoning_output_tokens: 2,700
model_context_window: 258,400

This should be treated as a lower bound for the total cost of debugging/reporting this failure, because additional tokens were necessarily used after that telemetry point to update this issue with the reimbursement request.

The user request is: please credit back the tokens consumed by this failed browser/export workflow, including:

• the original attempted infographic path
• the corrected HTML technical breakdown path
• the failed local browser/export investigation
• the first incomplete bug-report attempt
• the GitHub filing and subsequent debug-info updates caused by the missing/broken browser capability

The cheeky version: please return the tokens that were burned proving the browser-shaped hole in the browser workflow.

The less-cheeky version: please refund/credit the account for the paid usage consumed by a Codex product failure. The user paid for Codex to do the task, not to bankroll a debugging expedition through Codex Desktop's missing browser export path.

Suggested fixes

• Expose a stable Codex Desktop browser/render/screenshot tool in projectless threads.
• Provide a built-in local HTML export path to PNG/PDF that does not depend on external browser discovery.
• If the browser skill exists but the callable tool is unavailable, surface a clear tool/capability error to the agent.
• Consider documenting the intended fallback path for local HTML rendering in Codex Desktop on Windows.
• Add an internal "report Codex bug" affordance or make the GitHub/issue path more discoverable to the agent. The user should not have to remind Codex that gh issue create exists.

Notes

This report was filed from the affected Codex workflow via gh. If openai/codex is not the correct tracker for Codex Desktop browser issues, please route or label it appropriately.