Sourced buying guide · 5 min read
Codex Appshots is a screenshot plus whatever text the app exposes
A precise, documentation-first explanation of Codex Appshots, separating visible pixels, available accessibility text, conversation attachment behavior, and bounded GitHub failure reports.
Codex Appshots add a second payload to an ordinary screenshot: available app text.
It changes what Codex can infer from a screen, but only within a narrow contract. The official documentation describes the contract. Two public GitHub reports show what partial failures look like. Neither source supplies a product-wide reliability rate.
Contract in one table
OpenAI’s Appshots documentation gives us this working model:
| Layer | Documented behavior | Boundary |
|---|---|---|
| Image | Captures the visible frontmost app window | It is not a full visual capture of everything behind or below the window. |
| Text | Can include text the source app makes available, including text outside the visible scroll area | “Available” depends on the source app and its accessibility surface. |
| Permissions | Screen Recording is used for the image; Accessibility is used for available text | Permission is necessary for the payload, not proof that the payload will complete. |
| Destination | Defaults to a new chat, but a chat used within the last 60 seconds can receive the Appshot; consecutive shots stay together | The destination can be changed in settings. |
| Storage and sharing | The attachment is stored in the local session file, and the captured image/text are shared with ChatGPT | Local session storage is not local-only processing. |
| Limits | Some apps/sites may provide only the visible screenshot; CLI can resume a chat containing an Appshot but cannot create a new one | The feature is app- and surface-dependent. |
The May 18–22 OpenAI release note, alongside its May 21 public announcement, dates the Codex macOS launch and describes Command-Command as sending the frontmost window with a screenshot and available text.
A screenshot gives Codex pixels. Available text can give it labels, controls, and text the app exposes outside the visible viewport. Neither payload substitutes for the other.
The two payloads answer different questions
Pixels answer visual questions: Is the card aligned? Is the button too close to the edge? Is the hover state visible? Is the chart clipped?
Available text answers structural questions: What is the button called? What text does the app expose? Is there a heading lower in the scroll region? What label does the focused control have?
The combination is useful because visual work and text work fail in different directions. A screenshot can show a layout but omit text that is below the viewport. Accessibility text can expose a label but cannot tell a vision model what an off-screen illustration looks like.
An Appshot is a paired evidence packet, not a full export of the application state.
An Appshot becomes an attachment in a conversation. If the automatic destination sends it to a recent chat, that changes the privacy and context of the capture.
Report 1: text arrived, image did not
OpenAI Codex issue #27310 reports a failure on Codex app 26.608.12217, macOS 26.5.1, arm64.
The report includes a very specific state: the capture received a screenshot update, but the completed attachment failed with completed_without_screenshot. The log included hadAxText=true and hadScreenshot=false.
The log describes a partial-payload failure: text from the accessibility path was present, while the image was missing when the attachment settled.
The reporter also says Screen Recording and Accessibility were enabled, macOS’s own screencapture command worked, and the failure reproduced with Finder rather than only an Electron app. That makes a missing permission an incomplete explanation for this report.
On that reported build and machine, available text arrived without the screenshot. The issue page checked on 2026-09-18 showed no assignee or linked pull request. That status does not show whether the bug remains in newer builds.
Report 2: neither payload arrived on an Intel build
OpenAI Codex issue #24530, opened 2026-05-26, reports “Unable to attach appshot” on an Intel Mac using Codex Desktop build 26.519.41501.
This report is a different failure class. It says no screenshot or accessibility text was produced. The author inspected the installed bundle and reported that the expected SkyComputerUseService helper was absent, then connected the symptom to existing Intel Computer Use packaging issues.
The issue proposes either shipping the helper for Intel or clearly disabling Appshots on builds where the helper is unavailable. The page checked on 2026-09-18 showed no assignee or linked pull request.
That is evidence of a reported architecture-specific packaging problem. It is not evidence that all Intel Macs fail today, and it says nothing about Apple Silicon behavior beyond the fact that the issue is scoped to Intel.
Keep the claim smaller than the feature
These reports establish two plausible failure modes:
- a partial failure where available text is present but the image is missing;
- a total failure where the capture service produces neither payload.
They do not supply a denominator. There is no public count of attempted Appshots, active installations, successful attachments, affected builds, or time-to-resolution. A pair of detailed GitHub issues is valuable for debugging and test design. It is not a survey.
The official docs also establish a second limit: some apps and websites may provide only the visible screenshot, without the complete document or off-screen text. That means an Appshot can be working exactly as documented while still failing the user’s mental model of “send the whole page.”
The safe description is therefore narrow:
Codex Appshots capture the visible frontmost window and any text the source app makes available. The payloads can fail independently, and public GitHub reports document version- and architecture-specific failures.
Troubleshooting table
| Symptom or question | Version/report date | What the public source supports | Status checked 2026-09-18 |
|---|---|---|---|
| Available text present, screenshot missing | Codex 26.608.12217; macOS 26.5.1; arm64; log date 2026-06-10 | Partial-payload failure reported in #27310: hadAxText=true, hadScreenshot=false |
Public issue; no assignee or linked PR displayed. No product-wide rate inferred. |
| “Unable to attach appshot”; no image or text | Intel Mac; Codex 26.519.41501; issue opened 2026-05-26 | Architecture/helper packaging failure reported in #24530 | Public issue; no assignee or linked PR displayed. Intel scope only. |
| Does Appshot include off-screen text? | Current official docs checked 2026-09-18 | Only when the source app makes that text available; some apps/sites may be visible-only | Documented capability boundary, not a guarantee for every app. |
| Can CLI create a new Appshot? | Current official docs checked 2026-09-18 | A CLI-resumed chat can retain an existing attachment, but CLI cannot create a new Appshot | Documented limitation. |
Disclosure
Ali owns LazyScreenshots. That creates a conflict when he writes about LazyScreenshots or reviews competitors, so relevant pieces say so plainly. These articles are research and opinion, not independent third-party ratings.