This is a workflow regression.

Automatically converting long pasted text into an attachment removes direct edit-ability from the composer and adds friction to something that used to work properly. For coding, logs, research, drafting, translation, and long-form prompting, this is a downgrade.

“Show in text field” is not a real fix. It is a manual workaround for a problem introduced by the new behaviour.

Please add a persistent user setting to disable this.

Suggested setting:
Auto-convert long pastes to attachments: On / Off

Keep the current behaviour as the default if you want, but users need a real opt-out. This should be a preference, not a forced UI decision!!!

I am explicitly requesting:

  • a permanent setting to disable automatic paste-to-attachment conversion
  • restoration of normal inline pasting for users who opt out
  • composer behaviour that prioritises edit-ability over forced attachment handling

This change has made ChatGPT noticeably worse for my actual use case.

And right now it has changed the combination Ctrl + Shift + V to start the voice mode. Ooohhhh, how I hate that.

I agree.

A few problems with this forced Auto-convert longer pastes to attachments:

  1. It doesn’t save the file, and is expected to be only temporary. This is a major issue for both key word search for past conversations and version control.
  2. I can’t edit the body that is pasted.

I am also requesting:

  • a permanent setting to disable automatic paste-to-attachment conversion

  • restoration of normal inline pasting for users who opt out

  • composer behavior that prioritizes edit-ability over forced attachment handling

It’s almost unusable now, last work around is to copy the whole thing one small bit at a time.
Can deepseek code yet ? Because wow, this is way too unreliable

That’s heavily disrupting, by:

  • preventing basic lookup with ctrl+f on the chat window
  • making same thread revisits much harder, for example if we have 2 pasted blocks it’s unclear where would they be located in the main text
    and above that prevents prompt-editing and history changes (a prompt with attachment can’t be edited)

I was also extremely frustrated, and got to this thread in an attempt to find a solution with no luck.

HOWEVER, after that, I explored the settings, and found a solution! :tada:

If you go to ChatGPT’s settings → Keyboard, and then toggle “Toggle Voice” off, using CTRL + Shift + V will paste the text regularly without an attachment, similarly to other chat apps like Claude, and without activating voice mode instead.

Same issue, but in VS Code.
Who is the “genius” that decided that this is a good idea?
What if I need to paste several snippets and reference them in the specific sections of my prompt??

Command+Shift+V does not bypass it in the VS Code Extension!
What am I supposed to do?

I created this account specifically to raise this issue.

Earlier, I pasted my prompts for Deep Research, but it treated them as empty because it apparently could not “see” that the prompts were in the file attachments.

When I added wrapper prompts specifically asking Deep Research to execute the prompts in the attached files, it treated the wrapper prompts as the focus of the reports instead. It ended up doing meta-analysis about whether attached prompts should be executed, rather than actually executing them.

I was stuck for 30 minutes before finally figuring out that I had to paste my long prompts as plain text using Ctrl/Cmd + Shift + V.

Is this intended behavior? The current flow is extremely user-unfriendly when handling long prompts. Other platforms, such as DeepSeek and Gemini, do not have this problem.

Can the old behavior be restored, where long prompts can be pasted as normal chat messages instead of being converted into attachments?

If not, could Support explain why this design is necessary?

On a Mac: shift+option+command+v

OpenAI has added a new choice hich will “unwrap” the pasted item. “Show in text field” is “put it in the prompt” (not necessarily where you pasted an insert)

One additional consequence of this behaviour that I don’t think has been covered here yet: the automatically created paste attachments are being retained in ChatGPT Library.

I checked this with OpenAI Support. They confirmed that when a long paste is automatically converted into an attachment, it is treated as a file and saved to Library until manually deleted. There is currently no setting to exclude these auto-created paste attachments while keeping normal uploaded/generated files in Library.

My Library has consequently accumulated a large number of Pasted markdown... and Pasted text... files from ordinary text I pasted into conversations. I never chose to upload or retain those as files - the attachment was created automatically by ChatGPT.

This is particularly relevant to the earlier point in this thread that these paste files were expected to be temporary. With the current Library behaviour, they are not temporary unless the user manually deletes them.

Support has captured this as product feedback and asked me to check whether using Show in text field before sending prevents the Library item being created. I haven’t confirmed that yet.

I think auto-created paste attachments should either remain temporary, be excluded from Library by default, or only be retained when the user explicitly chooses to keep them.