Projects regression: ZIP files can no longer be added to Project Sources — minimal 168-byte ZIP reproduces

ChatGPT Bugs
1

Environment

  • Surface: Web

I am seeing a reproducible failure when adding ZIP files to ChatGPT Project Sources.

This appears to occur earlier than the Project-file raw-byte/materialization failures that have recently been discussed here: in my case, the ZIP cannot even be successfully added as a Project Source.

Environment

  • ChatGPT web
  • Paid account
  • Project with Project-only memory
  • Reproduced: September 21, 2026 (KST, UTC+9)
  • Project source-count limit was separately checked and is not the cause

Exact UI error
When I attempt to add a ZIP through Project Settings → Sources → Add, ChatGPT displays:

“소스를 추가할 수 없습니다
empty.zip을(를) 업로드하거나 처리하지 못했습니다”

English:
“Cannot add source.
Could not upload or process empty.zip.”

Minimal reproduction
I reduced the test case to an extremely small synthetic ZIP:

  • ZIP size: 168 bytes
  • Contents: exactly one ASCII-named text file
  • Uncompressed text size: 52 bytes
  • Encryption: none
  • Unicode filename/path: none
  • ZIP integrity: PASS
  • SHA-256:
    0d73f585d03eb3e310fa65da52d6d2dc4462d2957e6422cfd39098419627c8d7

The minimal archive fails in the same way.

This makes the following explanations very unlikely:

  • archive size
  • archive complexity
  • Unicode filenames
  • encryption
  • corrupt ZIP structure

Existing ZIP Project Sources

This same Project already contains ZIP assets that previously worked normally, including:

  1. 언어논술_PRESENTATION_BINDING_RUNTIME_PACK_v0.7_R01.zip

    • Size: 958,698 bytes
    • ZIP integrity: PASS

  2. LANGUAGE_ESSAY_CORPUS_RELEASE_v3.zip

    • Size: 17,215,003 bytes
    • Members: 3,589
    • ZIP integrity: PASS

So this is not a case where I am trying ZIP Project Sources for the first time. Existing workflows were built around ZIP archives as persistent Project assets.

Failure-domain distinction

I think it is important to distinguish this case from the previously reported failure:

“This Project file does not have an authorized raw-byte materialization path.”

That error concerns a Project file that already exists but cannot later be materialized into the execution environment.

My current reproduction appears to fail earlier:

upload / ingestion
→ processing
→ Project Source registration
→ [never reaches later materialization]

The UI explicitly says the ZIP could not be “uploaded or processed.”

These two problems may share infrastructure, but I do not think they should be assumed to be the same defect without backend evidence.

Open question: is ZIP support being removed?

Current OpenAI documentation lists common document, spreadsheet, presentation, image, and text formats, but does not clearly state whether ZIP is supported as a Project Source.

That leaves an important ambiguity:

  1. Was ZIP support for Project Sources intentionally removed?

or

  1. Is this a regression in the Project Source ingestion/processing pipeline?

If ZIP support was intentionally removed, it would be useful for OpenAI to clarify:

  • when this change became effective,
  • whether it applies specifically to Project Sources,
  • and how existing Projects containing ZIP assets are expected to migrate.

If ZIP is still intended to work, this looks like a reproducible ingestion regression.

Evidence available

I captured:

  • a screenshot of the exact UI error
  • a HAR during reproduction
  • the minimal ZIP reproduction file

I am not posting the raw HAR publicly because it may contain session/request information, but I have already provided it directly to OpenAI Support.

Support case:
#15493324

I would be especially interested to know whether anyone else can reproduce this specific failure:

Project Settings
→ Sources
→ Add
→ select even a tiny valid ZIP
→ “Could not upload or process [filename].zip”

In particular, it would be useful to distinguish:

A. ZIP works in a normal standalone chat but fails as a Project Source

B. ZIP fails both inside and outside Projects

C. Existing ZIP Project Sources still work, but newly added ZIPs fail

D. The problem is intermittent rather than deterministic

Those results would help determine whether this is a file-type policy change, a Project-specific ingestion regression, or another intermittent backend issue.

2

Went to test this on a Project, attempted uploading to Sources and got kicked back with:

Could not add sources
Could not upload or process XXXXX.zip

I can successfully add it to a Chat inside a Project and it can see the Zip and the contents just fine, however it then gets added to the Library despite the Project being “Memory: Project-only” and “Library access: Disabled” which is then counterintuitive.

Does not seem to be affected by Project Memory / Library access type, adding to Sources always seem to cause Zips to fail.

Worked earlier today for me prior to posting this, came back a few hours after and bonked against that error message.

3

There is now a second current report that makes this more interesting, but I would keep the failure domains narrow.

In topic 1400616, a Shared Project user reports that ZIP source uploads started failing after the September 24 UI change, and another user independently reports the same ZIP/tar.gz source-upload failure in that post-update window.

More importantly, the second report in this thread already gives a clean surface A/B:

  • the ZIP can be added to a Chat inside the Project and its contents are readable;
  • adding that same kind of ZIP to Project Sources fails with “Could not add sources / Could not upload or process …zip”.

That keeps the failure around Project Source ingestion / registration, rather than “ChatGPT cannot read ZIP files at all.”

One documentation boundary is important. OpenAI’s current Projects article explicitly describes adding PDFs, spreadsheets, documents and images as Project reference material, and the current supported-file-types article lists formats such as XLSX/XLS/CSV/TSV/DOCX/PPTX/PDF/TXT. Neither currently gives me a public guarantee that ZIP is supported as a Project Source:

So I would not yet state “OpenAI broke a currently documented ZIP guarantee.”

But your historical control still matters: this same workflow previously accepted ZIP Project Sources, existing ZIP sources remain in Projects, and the 168-byte valid archive eliminates size/complexity/encryption/Unicode/corruption as sensible explanations.

The clean product question is therefore:

Was ZIP support for Project Sources intentionally changed, or is the current ingestion path regressing?

I would also keep this separate from the other Shared Project failures reported today, such as cross-member branching authorization errors and stream-recovery timeouts, unless backend evidence actually links them.

4

Same here. Since today, I cannot load anymore zip files into my ChatGPT Web context Project! I can add any other file, but not zip.

On the UI I’m getting this error with a red top banner:
Impossibile aggiungere fonti
Impossibile caricare o elaborare .docs.zip

Which roughly means:
Impossible to add source
Impossible load or elaborate .docs.zip

5

I can reproduce on both Web and the newer ChatGPT desktop application; Plus plan, Windows.

On my end, this broke yesterday. I did upload a .zst as a source before the UI rollout on my end at 2026-09-24T04:38:24.715573+00:00. I tested both web and desktop application and I can add .tar.gz, .zst files into the file library, but I receive the same English error when directly uploading as a source. Newer sources from the file library picker of those formats are not exposed in the UI, but older ones are.

ChatGPT Classic application works. I am able to add .tar.gz, .zsts, zips, etc.

I assume this is some kind of client bug?

6

This has been a major thorn in my side since last night.

The only reason I can see why zip and tar.gz files arent uploading is because OpenAI explicitly blocked them on their supported clients during the UI update last night. If this was a legitimate bug, non-archive files should be affected too. But literally the only files I have issues with is all of the archival file formats.

I can’t believe there was no notifications about this. There is no way this was not intentional. If they didn’t mean to remove this feature with this UI update, you better believe they plan to in the near future.

Signing up to Claude for the first time ever today.

7

Hey @all! Thanks for bringing this to our attention.

We’re going to take a closer look into what’s happening here and will share an update once we have more information.

We appreciate your patience while we look into it.

- Sunny

8

Ive been adding zip files t a project for weeks, and in the last couple of days I get the same error as others are seeing.

the ZIP can be added to a Chat inside the Project and its contents are readable but adding that same ZIP to Project Sources fails with “Could not add sources / Could not upload or process …zip”. I can add them to the library without issue.

9

Just a quick update from my side: I can now add zip files into the project’s context, it seems fixed for me

11

Thanks for the detailed repro. I tested a 168-byte ZIP today with Project-only memory. It uploaded to Sources, and a new Project chat could read the file inside. Could you retry your ZIP in the same Project and let us know if it still fails?

12

Hi,

I retried the ZIP upload in the same Project, and it is now working
correctly on my side as well.

The ZIP was successfully added to Project Sources, and a new Project
chat was able to access the file inside it.

Thank you for taking the time to reproduce the issue and follow it
through. Please also pass along my thanks to the engineering team
involved in investigating and fixing this.

There is still a separate execution issue affecting the
sandbox/container environment, where container- and Python-backed
execution can fail with caas.internal.errors.ClientError. I hope the
engineering team can also identify and resolve that remaining issue,
as it continues to affect execution-dependent workflows.

Thank you again for the work on the ZIP issue.

Best,
Woo-cheol Cho

13

Thanks for confirming, Woo-cheol! Glad the ZIP upload and file access are working again. We’re still tracking the separate execution issue in your other thread.