[Windows] App Shot attach fails before capture starts, then recovers after a multiline draft
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 22/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- javascript
- Domain
- desktop-dev, frontend
Research direction
The report points at the renderer bundle webview/assets/app-initial-25361a10f2bf.js: the capture function a5s checks the attachment animation destination before it logs request creation, and the callback in Mxc returns null when attachmentsContainerRef.current is missing. Start by confirming whether that container is absent in the single-line layout, and see where the early return happens without a lifecycle log. Done means the early return is logged with its reason and an empty message box either attaches or shows a useful error. The intermittent recovery is unexplained, so reproduce it before changing anything.
Written by the indexing model from the issue text.
Description
What version of the Codex App are you using (From About Codex dialog)?
Windows package OpenAI.Codex, version 26.1002.7124.0, collected with Get-AppxPackage. The About dialog was not inspected.
What subscription do you have?
Not provided. This report concerns desktop App Shot capture and composer state.
What platform is your computer?
Microsoft Windows 11 Enterprise 25H2, build 26200.9550, x64.
What issue are you seeing?
App Shot repeatedly showed "Unable to attach app shot" after a PC reboot, using either the configured DoubleShift shortcut or the message box's + -> Attach [app] menu. Bringing Codex fully into view and retrying from an existing chat did not resolve it.
For the failing shortcut attempts, the desktop log showed target discovery and "Appshot shortcut started appshot", but no "Appshot capture request created", start-request, or completion records. The menu retries also produced no capture lifecycle records. The native helper and pipe had initialized successfully.
After entering a two-line draft (test, Shift+Enter, test) and retrying, capture and attachment succeeded. The screenshot and accessibility text arrived in the chat. Importantly, subsequent captures also worked with an empty message box, according to the user. This is an intermittent or state-dependent failure; an empty message box alone is not a reliable reproduction condition, and the two-line draft may have unblocked or initialized composer state.
What steps can reproduce the bug?
Observed sequence on 9 October 2026, GMT+8:
- Start Codex after rebooting Windows, and open a new or existing chat with an empty message box.
- Bring Google Chrome to the foreground and trigger App Shot with DoubleShift. Repeated attempts failed with the generic attachment error.
- Bring Codex fully into view and try + -> Attach [app] from an existing chat. The same error appeared.
- Enter a two-line draft without sending it, then trigger App Shot again. This attempt succeeded.
- Later, retry with an empty message box. The user reported success, and further capture successes were present in the log.
This is an observed recovery sequence, not a deterministic minimal reproduction. The exact state that originally caused the failure remains unknown.
What is the expected behavior?
App Shot should attach from an empty message box. If composer destination geometry is unavailable, capture should recover or provide a useful error and log the reason instead of silently returning before the request lifecycle begins.
Additional information
The failing shortcut attempts were at approximately 08:49 GMT+8. The first verified successful capture was at 08:57, completing in 1,448 ms with status=success, hadScreenshot=true, and hadAxText=true. Two further captures completed at approximately 09:08 in 1,024 ms and 1,058 ms. No application/runtime files or configuration were modified between the failed post-reboot attempts and these successes.
Possible frontend cause, not confirmed by live DOM inspection: in the installed renderer bundle webview/assets/app-initial-25361a10f2bf.js, capture function a5s validates the attachment animation destination before logging request creation or adding pending capture state. The callback in Mxc returns null if attachmentsContainerRef.current is absent. The normal single-line layout can omit the attachment container. A null destination triggers the generic attachment toast and returns without a capture lifecycle log. The outer shortcut can nevertheless log "started appshot" because it invokes that async function without awaiting it. This is consistent with the observed logs, but does not establish why the state later recovered and empty drafts started working.
Useful diagnostic additions would include whether the attachment container exists, the layout mode, UI scale, destination validation result, and the trigger source when this early return occurs.
The user also reports that Codex's window resizes every time App Shot is used, even when capture succeeds. This appears related to the existing window-state report #50476. The exact before/after bounds and maximized state have not been independently measured.
Related reports: #26051 (intermittent per-chat attachment failure on macOS) and #50476 (Windows App Shot window restoration/resizing). This report adds Windows pre-request failure evidence and the observed multiline recovery sequence.
Earlier, before the reboot, a separate native load_appshot_capture_source timeout was logged. That timeout did not recur in the successful post-reboot captures, and has not been established as the cause of the pre-request failures described here.
No private screenshots, browsing contents, full session transcripts, account details, or local user paths are included.
- Dominant language
- Rust
- Stars
- 129k
- Forks
- 20.3k
- Avg merge
- 1m
- Merged PRs (30d)
- 998
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from openai/codex
-
bug context
Difficulty 2/5 Under an hour Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
Standalone Unix updater reports success when curl fails (`curl | sh` masks the exit status); Windows path is unaffectedPossibly taken @akhil9tiet claimed this 1 day ago. Openbug CLI windows-os
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
openai/codex#54465 · 1 comment ·
Maintainers usually reply within 1 day
-
codex-skills-extension: pass ModelInfo context window in SkillsExtension::contribute_thread_contextOpenbug CLI context skills
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
documentation
Difficulty 1/5 Under an hour Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
apply_patch drops trailing spaces from filenamesPossibly taken @akhil9tiet claimed this 5 days ago. Openbug tool-calls
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
openai/codex#53245 · 2 comments ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
EmbarkStudios/cargo-deny#910 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
tursodatabase/turso#10054 ·
Maintainers usually reply within 1 day
-
build: Update rust versionPossibly taken A pull request linked to this issue is open or already merged. Opendependencies
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
ibm-granite-community/granite-cli#229 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
orottier/web-audio-api-rs#658 ·