ChatGPT Project Sources show total_lines: 0 while identical Library files work

ChatGPT Bugs
, , ,
1

Environment

  • Surface: ChatGPT Android app and mobile web
  • Subscription: ChatGPT Plus
  • Android version: Android 16
  • ChatGPT app version: 1.2026.209
  • Device: 24117RN76O
  • Affected feature: ChatGPT Projects → Project Sources
  • Project size: approximately 10 source files, below the applicable 20-file Plus limit
  • Model: not model-specific as far as I can determine

Bug

A valid UTF-8 TXT file is indexed and searchable when stored as a regular Library file, but the identical file added to Project Sources remains visible by filename while its extracted content is unavailable.
Expected behavior:
Chats inside the project should be able to access and search the text of files added to Project Sources.
Actual behavior:
The affected Project Source reports:
MIME type: text/plain
File size: 4,832 bytes
Extracted lines: total_lines: 0
All exact marker searches: 0 matches
The identical regular Library copy is indexed correctly: all 57 lines are extracted and all three unique markers are found.
This is therefore not a problem with the file contents, encoding, or format. The failure occurs specifically with the Project Source copy.

Reproduction

Create a valid UTF-8 TXT file containing 57 lines and three unique markers:
АЛЬФА-48271
БЕТА-59382
ГАММА-71604
Add one copy as a regular Library file.
Add the identical file to Project Sources.
Verify the regular Library copy: all three markers are returned correctly.
In a separate chat inside the same project, select the exact Project Source copy by filename and perform case-sensitive literal searches for the three markers.
Observe that the Project Source reports total_lines: 0 and returns zero matches for every marker.
Wait more than five hours and repeat the searches. The result remains unchanged.
Remove the Project Source and immediately add it again. The re-added copy is named:
project_source_index_test_utf8(1).txt
Repeat the same searches. The newly added copy still reports total_lines: 0 and returns zero matches.
The exact Project Source copy was verified using an exact Library filename search followed by case-sensitive literal Library searches within the selected file. No local file access, Python, shell, or previous conversation memory was used.

Diagnostics

This defect is silent: the Project Source remains listed normally in the interface, so there is no conventional error dialog or request ID. The failure is visible only when inspecting/searching the source and finding that it contains zero extracted lines.
Initial documented reproductions:
2026-09-06 19:37:59 UTC+3
2026-09-07 01:23:39 UTC+3

I have been experiencing Project Source access and indexing failures for more than a week. The controlled TXT reproduction of the total_lines: 0 state has been documented since September 6, 2026, and remains reproducible as of September 10, 2026.

The failure:
persists after waiting more than five hours;
persists after removing and re-adding the source;
occurs in another chat within the same project;
was also tested through mobile web;
remains reproducible.
OpenAI Support reviewed the controlled test and agreed that the source file itself is valid, that its text is extracted correctly outside Project Sources, and that zero search results from a source with total_lines: 0 do not establish that the markers are absent. They indicate that no extracted text is available for the affected Project Source copy.
The suggested workaround is to use the correctly indexed Library copy and attach it separately to individual chats. However, this does not provide the persistent project-wide access that Project Sources are intended to provide.
I am attaching a screenshot of the English diagnostic results. Can anyone else reproduce this difference between an ordinary Library file and the identical Project Source copy? I would also appreciate investigation by OpenAI staff into the Project Sources ingestion/indexing pipeline.

1000032286
10000322861080×2213 195 KB

2

Update — September 25, 2026

The issue is still reproducible.

OpenAI Support has now confirmed that the affected file is valid, that the failure is specific to the Project Source copy, and that the successfully indexed Library copy is only a temporary workaround. The support case remains open.

However, the latest clean-session tests show a second failure mode. Instead of selecting the Project Source and returning total_lines: 0, the session is not provided with the Project Sources retrieval/search mechanism at all. As a result:

  • the exact Project Source cannot be selected through the index;
  • total_lines and other source metadata are not exposed;
  • no requested excerpt can be retrieved;
  • no Library search, direct file reading, local copy, shell, Python, or chat attachment was used.

This does not demonstrate that the original total_lines: 0 issue has been fixed. The failure is now occurring before the index can even be queried.

Two observed states now need to be distinguished:

  1. Project Sources retrieval available → source selected → total_lines: 0 → no matches.
  2. Project Sources retrieval unavailable → source cannot be selected → index cannot be tested.

Direct reading of the DOCX still works, but that is a different access path and does not validate Project Sources indexing.

The user-facing result remains the same: shared Project Sources cannot be searched and cited reliably across project chats.

3

Update — October 8, 2026

The issue remains unresolved. The Library route previously suggested as a partial workaround has also become unreliable when accessing files from chats.

Additional observations:

  1. File access fails in the interface

A generated file appears in both the project chat and Library. Opening it from the Android chat produces “Library file not found”. On mobile web, the file viewer displays “Preview unavailable”, and the Download button does not respond.

Opening the same file directly from the Library interface still works: Android offers an application chooser, and the file can be opened and saved through another application.

  1. Chat reports unsuccessful Library content retrieval

In another example, ChatGPT reported finding a 68-page PDF in Library but being unable to retrieve its text. The chat response reported total_lines: 0 and “No readable content was found in this file for the requested mode.”

These are results reported in the chat; I cannot independently verify the underlying extraction or indexing state.

  1. Recent Project Sources searches could not be performed

During controlled tests of project_source_index_test_utf8.txt, ChatGPT reported that no suitable Project Sources search/retrieval tool was available in the session and that no source-search call was made.

The test prompt explicitly restricted access to Project Sources and excluded Library, local copies, direct full-file reading, and other fallback methods. It also instructed ChatGPT to use the label “NOT TESTED” if a search could not be performed. That label was part of the requested reporting format, not an application error.

These tests therefore provide no new match counts or total_lines result. They also do not establish that the previously documented total_lines: 0 behavior has been resolved.

The broader problem has persisted across multiple private projects and files. Repeated testing through web and different Android app versions, including new projects and new project chats, has not restored reliable access.

OpenAI Support has confirmed that the case remains open and that the earlier evidence is retained. Screen recordings and a fresh web HAR capture have now been submitted.

The practical problem remains: files visible in Project Sources or Library cannot be used reliably from project chats.