›_ Codex Issues
Codex Issues / #39905

Codex App: Skill and App mentions do not round-trip correctly through copy/paste

Open 💬 4 comments Opened Aug 21, 2026 by FerdiHS

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.818.22352

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Copying a previously submitted Codex prompt that contains Skill mentions and then pasting it back into the Codex composer does not preserve the Skill mentions correctly.

This happens with both ways of copying a previous prompt:

  1. manually selecting the prompt and pressing Cmd+C; and
  2. using Codex's built-in Copy button.

Both methods produce the same issue when the copied prompt is pasted back into Codex.

The original prompt contains rendered Skill mentions/chips. However, when the clipboard contents are inspected as text, the Skill mentions are represented as Markdown links pointing to local, version-specific SKILL.md files.

For example, with personal information redacted:

[$ponytail:ponytail](/Users/<user>/.codex/plugins/cache/ponytail/ponytail/4.9.0/skills/ponytail/SKILL.md)
medium

[$superpowers:receiving-code-review](/Users/<user>/.codex/plugins/cache/openai-curated-remote/superpowers/6.3.0/skills/receiving-code-review/SKILL.md)&#x20;

When this content is pasted back into the Codex composer, the serialized Markdown/URI representation is inserted literally instead of reconstructing the original rich Skill/App mentions.

This breaks the normal workflow of copying a previous development prompt, pasting it, making a small modification if necessary, and immediately submitting it.

It also makes it unclear whether the exact Skill invocation/configuration from the original prompt has been faithfully preserved.

What steps can reproduce the bug?

  1. Open the Codex App.
  2. Create a prompt containing one or more Skills selected through the Skill picker. For example:
  • ponytail:ponytail, with medium
  • superpowers:receiving-code-review
  1. Submit the prompt so that the Skill mentions appear as rendered Skill entities in the previous user message.
  2. Copy the submitted prompt using either:
  • manual text selection followed by Cmd+C; or
  • Codex's built-in Copy button.
  1. Paste the copied prompt into the Codex composer.
  2. Observe that the Skill mentions do not round-trip to the same representation/layout as the original prompt.
  3. Optionally paste the same clipboard contents into a plain-text editor. The Skills are represented as Markdown links to local, version-specific .codex/plugins/cache/.../SKILL.md paths.

The issue reproduces with both Cmd+C and the built-in Copy button.

What is the expected behavior?

A Codex prompt containing Skill mentions should survive a:

Codex → clipboard → Codex

round trip without changing the Skill mentions or requiring manual reconstruction.

In particular, copying and pasting a previous prompt should preserve:

  • the same selected Skills;
  • any associated Skill configuration/arguments;
  • the surrounding prompt text and spacing; and
  • the ability to immediately submit the reused prompt.

The expected workflow is:

copy previous prompt → paste → optionally edit → submit

Users should not need to manually remove and re-select every Skill after pasting a previously used prompt.

Ideally, clipboard serialization for Skill mentions should use a stable Skill identifier rather than an absolute, version-specific local plugin-cache path such as /Users/<user>/.codex/plugins/cache/.../SKILL.md.

Additional information

The same copy/paste workflow worked correctly in previous versions of the Codex App: Skill mentions could be copied from an earlier prompt and pasted back into the composer without this malformed/reconstructed representation.

I first noticed this issue in Codex App Version 26.818.22352.

This has a noticeable workflow impact for development tasks where prompts containing multiple Skills are intentionally reused across implementation and code-review iterations.

A previously fast workflow:

copy previous prompt → paste → modify if needed → submit

now requires checking and potentially reconstructing the Skill mentions before every submission.

The behavior is not specific to manual text selection: both Cmd+C and Codex's built-in Copy button produce the same result.

The clipboard representation also exposes implementation-specific information such as the user's local home-directory path, plugin cache layout, and cached plugin versions. I have redacted my local username from the examples in this report.

Possibly related issues:

  • #25609 — Plugin skill paths leak mutable marketplace cache commit into model-visible context
  • #31716 — Clipboard copy/paste loses ordered and bulleted list formatting

#25609 appears related to exposing local/mutable SKILL.md paths, while #31716 covers another Codex clipboard round-trip problem. Neither appears to report this specific failure of Skill mentions to round-trip correctly through copy/paste.

I am attaching screenshots showing:

  1. Original prompt before copying — Skill/App mentions render correctly

<img width="756" height="266" alt="Image" src="https://github.com/user-attachments/assets/d13a75f3-ec30-45b5-84eb-43e86972d40e" />

  1. Raw clipboard contents after copying the prompt (username redacted)

<img width="1146" height="274" alt="Image" src="https://github.com/user-attachments/assets/6875bde5-63e4-4871-9adc-a4b97b90a579" />

  1. Same clipboard contents pasted back into the Codex composer (username redacted)

<img width="1490" height="482" alt="Image" src="https://github.com/user-attachments/assets/3c26d5a8-96dc-4367-9468-0c5410ae2dc9" />

View original on GitHub ↗

4 Comments

FerdiHS · 6 days ago

Additional technical investigation

I performed a read-only inspection of the packaged frontend in Codex Desktop 26.818.22352 to better understand where the round-trip appears to break.

Observed behavior in the packaged frontend

The two copy methods appear to use different clipboard paths:

  • The built-in user-message Copy action calls navigator.clipboard.writeText(...), so it emits a flattened text/plain representation and does not preserve a custom structured mention payload.
  • Manual Cmd+C goes through a separate Markdown copy path that writes text/plain and text/html. That path serializes prompt-link / mention atoms into linked Markdown forms such as [label](path).

The composer also contains Markdown restoration logic that can create structured app/plugin/skill mention nodes from pasted content.

This means the problem does not appear to be that mention restoration is completely absent.

Likely failure boundary

Based on the reproduction and the packaged frontend, the likely failing boundary is:

structured Skill/App mention
→ clipboard Markdown/text representation
→ paste restoration/rebinding
→ structured Skill/App mention

In other words, this looks like a serialization/restoration contract mismatch or partial rebinding regression: rich mentions are flattened during copy, but the representation reaching the composer is not reliably reconstructed into the original structured mentions.

This would also explain why both manual Cmd+C and the built-in Copy action reproduce the visible issue even though they use different clipboard implementations.

Relevant implementation details

In the packaged frontend I found the relevant paths around:

  • built-in Copy: subagent-activity-chip-group-CK7te49n.js (g_)
  • shared Markdown copy handling: app-initial-2HRzhJVF.js (Yra, ata, ota, dta)
  • mention serialization: PV
  • composer paste handling/restoration: YUa.handlePaste, WZr, KZr, ZZr, JZr

The public Codex source is consistent with this representation model:

  • UserInput::Skill and UserInput::Mention represent Skills/App mentions structurally.
  • codex-rs/tui/src/mention_codec.rs separately serializes linked mentions for history as [$name](path) and contains decoding support for paths such as app://..., plugin://..., skill://..., and .../SKILL.md.

I have not identified a specific regression commit, and I am not claiming that the Rust history codec itself is the failing component. The evidence points more generally to the Desktop copy/paste representation boundary.

I also could not conclusively determine the origin of the trailing &#x20;. The packaged bundle does not contain that literal string, so it may be introduced by HTML/clipboard serialization rather than by the mention codec itself.

No files, configuration, caches, databases, clipboard contents, or installed application components were modified during this investigation.

If additional diagnostics, clipboard-format inspection, or validation against a candidate/test build would be useful, I'm happy to help reproduce and test this further.

omarpinarecords · 5 days ago

Still reproducible in the ChatGPT desktop app's Codex surface on macOS, version 26.818.41509.

The raw entity is visible in the submitted user message/transcript, not only in plain-text clipboard contents. In one reproduction, a Skill mention was serialized in the form [$openai-docs](…/SKILL.md)&#x20;, and the trailing &#x20; was displayed literally instead of as a space. I also observed the same trailing literal entity after a task-link mention.

I cannot provide an in-app Feedback ID because the feedback submission flow is also failing and does not complete. I can add the Feedback ID later if that submission flow becomes available.

omarpinarecords · 4 days ago

Follow-up: the in-app feedback submission is working again. Feedback ID: 01a02dc5-37e5-78e0-a36e-b556e3a89256

FerdiHS · 1 day ago

Still reproducible in Codex Desktop 26.820.60940 on macOS.

I re-tested the original reproduction from this issue and Skill/App mentions still do not round-trip correctly through copy/paste.

The behavior remains consistent with the existing report: the copied rich mention is serialized into its Markdown/path representation instead of being reliably restored as the original structured mention when pasted back into the composer.