›_ Codex Issues
Codex Issues / #28622

Appshots fail with “Unable to attach appshot” when pressing hotkey in 26.611.61049

Open 💬 3 comments Opened Jun 16, 2026 by GGBondBlueWhale
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

After updating Codex Desktop to version 26.611.61049, the Appshots feature does not work. In the Appshots settings page, the configured hotkey is pressing both Command keys simultaneously. When I press the hotkey, Codex shows an error toast:

Unable to attach appshot

So the appshot is not captured or attached.

Environment

  • Codex Desktop version: 26.611.61049
  • macOS: Tahoe 26.5.1
  • Device: MacBook Pro 16-inch, Apple M5 Max, 128 GB memory

Steps to reproduce

  1. Open Codex Desktop version 26.611.61049.
  2. Go to Settings / Computer use / Appshots.
  3. Use the default Appshots hotkey, pressing both Command keys simultaneously.
  4. Observe the error toast.

Expected behavior

Pressing the Appshots hotkey should capture the frontmost window and attach the appshot to Codex.

Actual behavior

Codex fails to attach the appshot and shows:

Unable to attach appshot

Impact

This makes the Appshots feature unusable. Since Appshots are intended to provide Codex with the frontmost window's visual and text context, this is a serious issue for workflows that rely on sharing app/window state with Codex.

Please investigate why Appshots cannot be attached in the latest Codex Desktop build.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #27176
  • #28600
  • #28485
  • #28604

Powered by Codex Action

Keesan12 · 2 months ago

This feels like one of those failures where capture, attach, and composer-insert are being treated as one step, so the toast hides the actual break point.

If you split the telemetry into capture_started, asset_written, asset_registered, and composer_attached, support can tell immediately whether the hotkey path broke, the temp artifact failed, or the attach handoff regressed in the latest build. That usually turns an opaque desktop bug into a fast repro.

SocialK · 2 months ago

after installing the latest Microsoft Store build:

Current versions observed:

  • Microsoft Store / Windows package version:

OpenAI.Codex 26.611.7849.0
PackageFullName: OpenAI.Codex_26.611.7849.0_x64__2p2nqsd0c76g0

  • In-app About Codex dialog:

Version 26.611.61049 • Released Jun 16, 2026

Result after the update:

The application now opens, which is the only visible improvement compared to the previous update where the app did not open properly.

However, none of the main regressions appear to be fixed:

  1. Startup is still very slow.

Codex now takes around 20 seconds to open. Around one month ago, it opened almost instantly.

  1. The application still lags.

The user interface is still noticeably sluggish. Around one month ago, the app was responsive and did not lag like this.

  1. Old sessions still do not load.

Sessions from around one week ago fail to open.

  1. Opening old sessions still causes severe memory pressure.

When trying to open older sessions, system memory usage goes up to around 90% RAM

  1. This is a major regression compared to the previous working behavior.

Around one month ago, everything was fast and stable. Even a very large session/history state of around 50 GB could load in seconds.

Conclusion:

Version 26.611 improves only the basic startup failure: the app window can now open.

But the core issues are still present:

  • slow startup
  • laggy user interface
  • old sessions not loading
  • severe RAM growth when trying to load old sessions

From my side, this version does not fix the regression introduced in the recent Windows desktop updates. It only changes the failure mode from “the app does not open properly” to “the app opens, but is still slow, laggy, and unable to load existing sessions safely.”