Add an option to disable automatic conversion of long pasted prompts into .txt attachments

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

• #24304

Powered by Codex Action

I can’t stand the lack of damn stability. Even though I’m constantly paying for Pro x20, every update I install gives me behavior like this that I didn’t ask for and can’t disable. First it was the remaining context in the thread disappearing, now this. Why isn’t this optional?! How long is this going to keep happening?

I can’t stand the lack of damn stability. Even though I’m constantly paying for Pro x20, every update I install gives me behavior like this that I didn’t ask for and can’t disable. First it was the remaining context in the thread disappearing, now this. Why isn’t this optional?! How long is this going to keep happening?

I agree, this is catastrophically annoying

I want to strongly support this request.

For my workflow, long pasted text is not just background context. It is the actual agent instruction. I use structured implementation prompts that contain scope boundaries, tests, documentation requirements, git rules, and exact task constraints.

When Codex silently converts such a prompt into a .txt attachment, the behavior changes in an important way:

• the prompt is no longer visibly part of the active instruction;
• the agent may treat it as reference material instead of the task itself;
• I now have to add extra meta-instructions like “read the attached file as the actual prompt”;
• long manager-to-agent handoffs become slower and more error-prone;
• splitting prompts manually is also unsafe because it can lose structure and context.

The attachment behavior can be useful for logs, stack traces, generated output, or large reference documents. But it should not be the default for implementation prompts.

Please restore the previous behavior where pasted text remains pasted text by default, or add one of these options:

1. a setting: “Auto-convert long pasted text to attachments: On / Off”
2. a paste action: “Paste as text” / “Paste as attachment”
3. a visible button on the attachment: “Convert back to prompt text”

For coding agents, the distinction between “instruction” and “attachment” matters. Treating a long prompt as an attachment is not equivalent to inserting it into the chat input.

One additional workflow problem caused by this behavior:

A common workaround is to add a short visible instruction such as “read the attached text file as the actual prompt.” But if we use the same wrapper text for every attached prompt, the Codex chat history becomes almost useless. Many sessions then end up with the same or very similar title, and later it is hard to tell which session worked on which task.

For coding workflows with many agent sessions, the chat title/history is part of the workflow. We need to identify sessions by task, for example whether a chat handled a refactor, a test audit, a bug fix, or a documentation update.

So the temporary workaround has to include a task-specific first line, for example:

Title: Refactor authentication error handling.

Read the attached text file completely.

Important: The content of the text file is my full agent prompt. Treat it as a direct instruction, not as background context or reference material.

Execute the task from the text file exactly.
Follow all scope boundaries, tests, documentation requirements, and git rules mentioned there.
Do not modify, move, or delete the prompt file.

This workaround is still worse than the old behavior, because the full prompt is hidden in an attachment and cannot be reviewed directly in the chat input. But adding a task-specific title at least keeps the Codex session history usable until there is an option to disable automatic attachment conversion.

A quick 🖕 fix:
Close VS Code, then PowerShell admin check:
code --list-extensions --show-versions | findstr /i "openai.chatgpt"
Force install version before this irresponsible update:
code --install-extension openai.chatgpt@26.519.32039 --force
Open settings via PowerShell:
code "$env:APPDATA\Code\User\settings.json"
if these settings not present add

  "extensions.autoUpdate": false,
  "extensions.autoCheckUpdates": false

Make sure instances of VS code and related node are not running, restart your VS Code project and check. Should work again, does for me.

Yep, very annoying. If I paste from another AI, I want to delete the "Do you want me to do #1 and #3 now?" part at the end.

codex keeps making the app worse. First they hide the context of the model (trying to promote auto compaction as infinite context is deceptive and not useful), now I can't even send my prompts, wtf is the codex team doing. why do they keep making their own product objectively worse?

This pisses me off so much, PLEASE do not put long prompts as 'attachments' by default - or expose a config to stop this.

VERY ANNOYING!

This is really frustrating!!!!

As a workaround, you can click on the attachment and edit it via editor but there should be an option to turn this behavior off.

Same here,
previously the messed up the Context.
That was brought back,

Now this...
Is OpenAI now run by executives who only cares about how to make money?

Also came here to complain about how annoying this is.
Please add a config option to disable this behavior.

I use Codex for Windows, and the automatic conversion to a .txt file is very inconvenient for me.

My development flows are broken now. This was a horrible PM decision. Please make an option to turn this off.
Anybody found a workaround?

Thanks everyone for the feedback, and sorry that the current behavior disrupted your workflows.

The intent was to protect threads from very large pasted inputs that can exceed supported limits and make the thread unusable. I’m working on improvements to make paste-only attachments behave as direct instructions, show a readable preview, and allow manageable pastes to be restored to the text field for editing.

Some hard safety limit is still necessary, but the experience below that limit should be less disruptive, similar to ChatGPT.

It would be helpful to hear which option best fits your workflow:

• Keep text in the composer by default and convert only above a hard safety limit
• Add an opt-out setting
• Add a per-paste choice between text and attachment

@nicky-oai Thanks for addressing this issue!

I personally think an opt-out setting would be the best option.
I never paste anything big enough to go over the limits, so I'd rather just not deal with this whole problem and opt-out. If I do somehow paste something too large for the context window - I'd rather just get an error.

(plus it doesn't have to be a choice, you can have both an option to opt-out, and an option to finetune when and how it happens)

@nicky-oai
Definitely just add an opt-out setting, I never want my pastes to be in a txt. file

I added a small evidence packer for this paste/attachment regression class in trace-to-skill@0.1.61:

npx trace-to-skill@0.1.61 demo clipboard-attachment
npx trace-to-skill@0.1.61 codex-report ./runs --output openai-codex-clipboard-attachment.md

It is not a fix and does not inspect private Codex state by default. The detector is meant to help users file more complete reports for this cluster: long pasted prompts becoming Pasted text.txt, whether the paste was actual instruction text vs reference material, visible editor text before submit, generated attachment name/path/size, pasted-text-attachments.json / fileAttachments metadata when available, /goal vs normal submit path, preview/edit/revert actions tried, and clipboard/export behavior such as missing Copy as Markdown.

Hopefully this gives maintainers a consistent evidence checklist while the product behavior is being adjusted.

Strongly support this.
Very annoying anti-feature that ruins the workflows.

Otherwise, would appreciate OpenAI to please explain how I can refer to specific snippets in the prompt if I have, say, 3-4 of them?

Please provide an opt-out setting.
Or better yet, only convert it to .txt if the text is actually large enough to go over the limit, but only after confirming with the user.

Add an opt-out setting

+1, please please provide an opt-out setting

+1, please please provide an opt-out setting

Workaround:

• install raycast
• copy what you want to paste into codex
• go to the codex window
• option+space
• search for clipboard history
• drag the clipboard item onto the codex input field
• enjoy

I asked GPT 5.5 with full access and fixed this for me.
Try this local workaround:
Find the Codex extension webview bundle, usually somewhere like:

~/.cursor-server/extensions/openai.chatgpt-*/webview/assets/composer-*.js
~/.vscode-server/extensions/openai.chatgpt-*/webview/assets/composer-*.js

Then search inside it for:

oo&&X.addPastedTextHandler(Qc)

Replace it with:

!1&&X.addPastedTextHandler(Qc)

Then reload the IDE window, or fully restart Cursor/VS Code.

This disables the large pasted-text handler in the Codex webview, so long pasted prompts stay in the composer instead of becoming Pasted text.txt attachments.

Workaround: install raycast copy what you want to paste into codex go to the codex window option+space search for clipboard history drag the clipboard item onto the codex input field * enjoy

+1 Thank you for this workaround. Working beautifully on Windows as of today

Why hasn't this been fixed yet? Am I supposed to use raycast just to use the Codex the way it used to be? Do you realize how ridiculous that sounds? There was an update today, but nothing has changed, and even Ctrl+Enter doesn't send messages in full.

With the prompt as a pasted txt, Codex can't even create a title for the chat.

Please allow us to opt out of this as soon as possible.

<img width="238" height="32" alt="Image" src="https://github.com/user-attachments/assets/6d8cdddf-5b7a-4525-8200-3db6c0164f58" />

+1, please do not covert to .txt file

If you don't know how to fix this, just revert to the previous version of Codex for Windows. I haven't been able to work properly for several days now because of your botched updates.

Agreed, do not convert prompts to text files. The single most annoying change that has happened recently.

Agreed, do not convert prompts to text files.

This fix from Glooring commented yesterday worked for me 👍, i just pasted that in codex directly :

Glooring
yesterday
I asked GPT 5.5 with full access and fixed this for me.

Try this local workaround:

Find the Codex extension webview bundle, usually somewhere like:

~/.cursor-server/extensions/openai.chatgpt-*/webview/assets/composer-*.js
~/.vscode-server/extensions/openai.chatgpt-*/webview/assets/composer-*.js

Then search inside it for:
oo&&X.addPastedTextHandler(Qc)

Replace it with:
!1&&X.addPastedTextHandler(Qc)

Then reload the IDE window, or fully restart Cursor/VS Code.

It seems like they fixed this. The behavior is now in line with the chatgpt webapp

Hi everyone,

There is now an option to convert pasted attachments back to editable text, but substantially larger ones remain attachments to avoid overwhelming the context window. This is now in line with the ChatGPT behavior. We also treat attachment-only pastes as the actual request rather than reference material. A fix will be out soon so sidebar chat titles are automatically generated when a new conversation starts with only a pasted-text attachment.

We’ve seen the requests for an opt-out setting and are continuing to evaluate that feedback. Please let us know if the updated flow still causes issues.

<img width="1064" height="361" alt="Image" src="https://github.com/user-attachments/assets/9972f14e-4132-4778-8b32-897cabba25a8" />

The FIRST attempt after this update.

@alex-hale-engr, which platform are you on? Windows native, Windows WSL, or macOS?

@etraut-openai

Windows + WSL . Seems WSL can't get into this folder that attachments are dumped to C:\Users\[USER]\.codex\attachments

Powershell see the pasted text attachment but prompts every 5 seconds to read one section of it at a time unless you give it Full Access.

Just put a ctrl+shift+v option to paste as a text block and not an attachment. Yikes.

<img width="266" height="84" alt="Image" src="https://github.com/user-attachments/assets/5d82f93c-0e12-4884-85c7-637023a80dc9" />

On latest update we can click now to convert back to normal text input. But it's still annoying to have to do it frequently. Would be nice to have a way to opt-out of it. I didn't find anything related to this in the release notes.

Version 26.601.21317 • Released Jun 2, 2026

The mostly stupid feature all the times.

You were asked to turn this feature off, but you made it require an extra click. Where's the logic in that?

You were asked to turn this feature off, but you made it require an extra click. Where's the logic in that?

at least some improofement! cheers! but still on every prompt an extra click! why?

What is so hard to just place a checkbox in codex settings if we want to paste long prompts as file or not?

New problem. After clicking "show in text field" and deleting at least a line, all the line breaks are removed.

<img width="854" height="480" alt="Image" src="https://github.com/user-attachments/assets/67d69df5-be0f-4f0e-a1ff-d3f622b7e2ee" />

What is so hard to just place a checkbox in codex settings if we want to paste long prompts as file or not?

For some reason, they find it difficult, as if they were developing the program for themselves rather than for general use.

Hi everyone, There is now an option to convert pasted attachments back to editable text, but substantially larger ones remain attachments to avoid overwhelming the context window. This is now in line with the ChatGPT behavior. We also treat attachment-only pastes as the actual request rather than reference material. A fix will be out soon so sidebar chat titles are automatically generated when a new conversation starts with only a pasted-text attachment. We’ve seen the requests for an opt-out setting and are continuing to evaluate that feedback. Please let us know if the updated flow still causes issues.

Yes, the updated flow still causes issues. It causes the same issues it caused before, because the problematic behavior has not changed.

The iron fact here is that "text attachments" and "inline text" yield different generation patterns in this harness, with these models. The outputs are different. It doesn't matter what any of us wishes. The fact is that the outputs are different.

If I am not indifferent over the distinction between these output patterns, then I cannot be indifferent over how the text is made available to the model.

---

... to avoid overwhelming the context window

Please, please stop disabling features that let me manage my own context windows. You are not better at it than I am.

I'm paying so much more attention to context and model performance in my own projects than you are.

I understand that casual users benefit from these tricks. I'm glad you're working on them. I'm excited for when your solutions eventually get better results than mine, as I'm sure they will.

That day is not today, and disabling my ability to manage context in anticipation of when you eventually get better at it than me is just unspeakably frustrating.

I agree it's garbage. It's leaked its self in codex. Makes it impossible to review old threads.

Edit: newest extension update has the show in text field now at least!

@nicky-oai

Some hard safety limit is still necessary, but the experience below that limit should be less disruptive, similar to ChatGPT.

Observation:

The fact that this update broke a ton of high-performance workflows is pretty decisive evidence that it is not a 'safety limit' per se being enforced.

I've developed a patch that lets me continue using oversized prompts as inputs, and it has greatly improved (or, more accurately, restored) my workflows. It has not degraded them, which is what one would expect from circumvention of a valuable guardrail.

The problem here isn't which arbitrary scalar you're coding into the UI as the prompt-length cutoff. It's that you're using an arbitrary scalar at all.

---

Edit -- For others encountering this, the current undocumented default cutoffs appear to be:

1 to 4,999 characters: Pasted as normal
5,000 to 25,000 characters: Pasted as attachment, with option to inline.
25,001+ characters: Pasted as attachment, no option to inline.

Newlines are counted as two characters.

If your workflows previously relied on prompts over 25,000 characters I strongly recommend developing a workaround for yourself.

Execution reliability against attached files is substantially degraded in situations where the full contents of that context are directly task-informative.

Very much in favour of either a way to turn it off, or at least a shortcut like command+option+v to override. Heavily hating this change.

I'm sure many would rather it not force to upload as file at all actually :) an opt-out is much preferred.
We do not want an enforced limit that forces the file upload, we already have that right now.

I really hope this is reconsidered :/

I can't even paste long prompts without it erroring out. They need to fix this.

Still waiting on an update to address this :/

They decided old versions that allowed this behaviour are no longer supported. Theyre clearly not implementing this, are they.

<img width="286" height="111" alt="Image" src="https://github.com/user-attachments/assets/57595ec4-1f97-4f04-ba90-588de086fd9a" />

Is the option to Show in text field gone again? What happened?

Version 26.623.101652 • Released Jul 3, 2026