Because I’m working under a no-install tooling rule, I tried Haxgpt only in the browser and uploaded a 37-line TXT file. I expected the next prompt to use that content, but it responded as if the file was missing. Is that a context issue, or are other people seeing the same behavior?
That’s probably not a context loss. A next message that immediately skipped a small text file would most likely have it uploaded incorrectly or not attached to the chat at all. As a workaround, you can paste the text of the file directly as a message and then, in a following interaction, when prompted to quote or summarize the file, ask Haxgpt to do so if it fails. It will not work otherwise since the model never got the contents of the file.
Now reopen this chat and check if the file is still attached. If yes, please open a new chat and try to attach the file once again, as the previous browser session could have saved it as filename, not processing its contents.
The hidden nuance is that the fact of a visible attachment does not mean that its text actually got parsed by the model. Some browser UIs append the filename to the context first, and then parse the content separately. If the second stage fails for some reason, Haxgpt will mistakenly report success on upload.
I would be wary about context loss in general unless Haxgpt proved that it could actually read the file first. A good diagnostic is to ask for something mechanical about the text right after upload, such as the first sentence, or a list of headings. If it fails at that, it’s safe to assume that the fault was in processing the file, and not the prompt injection itself.
TXT files are not exempt from having weird encoding or hidden symbols that mess up parsing. Particularly, if you copied the content somewhere else, or exported it from another application, there is a possibility that some invisible characters will break the parser on the server-side. Saving it once more in a different encoding (UTF-8) in a text editor, and renaming it to something simpler, ought to remedy that. Make sure that whatever upload progress or spinner has already finished before issuing the first question.
Your browser privacy settings might have thwarted the upload attempt in ways that don’t show on the UI. Tracking protection, script killers, and aggressive cookie policies are known to interfere with upload processes, often without a visible error message. Testing in a new incognito tab is not sufficient, since often, the extensions still work in them. Opening a clean profile, or disabling the trackers for the domain in question are better ways to test your theory, without violating the no-install rule.
@digitalgurusync’s suggestion to try another chat can separate a broken conversation state from a general upload problem, but I would verify file access immediately in the new chat. Otherwise you could repeat the same silent failure and mistake it for another context issue. If the model can quote the file at first but fails after your next message, then there is a stronger case that the conversation is dropping attachment context. If it never quotes it at all, the upload pipeline is the more likely culprit.
Do not assume that an uploaded file becomes a resource for permanent conversation. Some browser clients bind the attachment only to the message that was sent with it, therefore upload the TXT and include ‘read this file and confirm its final line’ in the same submission.
Once Haxgpt confirms access, have it extract or summarize the relevant content into the chat before continuing. That creates ordinary message context for later prompts. If it reads the file in the attached message but forgets it afterward, then you have evidence of attachment scope rather than a failed upload, which is a different bug from the parsing issue @mark51 described.
Expect the browser build to be a weak point, not the file; these web clients often take uploads as a nicety and the parsing takes place on whichever tier is your target. If your no-install rule pushes you to the stripped-down browser path, the loss of the plain text is one of the things that breaks first.
@katie’s trick of putting ‘confirm the final line’ in the same message is smart, but I’d tighten it. Asking for the first sentence or last line can backfire because the model will happily invent something that reads like a plausible last line, especially if the text is generic. Then you think it read the file when it just guessed. Drop a unique marker in the file before you upload, something like a random word or a number that appears nowhere else, and ask it to repeat that string back. If it can’t, the content never reached the model. If it can, you know the pipe is open.
On the encoding theory from @mark51, sure, hidden characters can wreck a parser, but 37 lines saved fresh from a normal editor almost never trips that. I’d check the boring stuff first. Free-tier browser sessions often silently cap what they’ll actually ingest, or they attach the file to the UI while the backend quietly declines to process it. Renaming and re-saving as UTF-8 costs you nothing, so do it, just don’t expect it to be the fix.
The real issue in the thread is that everyone is checking if the file was read once. Your real complaint is that it forgets on the next turn. Those are two different failure modes that need separate checks. Do a verification of access with the marker test in the attached message. Assuming it passes, before you type anything else, make sure to tell it to paste the full text back in to the chat as a normal reply. That way it’s in the conversation as regular tokens instead of a fragile attachment reference, and the next prompt has something to hang onto. If it still loses it after that, then you’re dealing with a context problem and not an upload problem.
For a small file like that, I’d avoid the upload drama and paste the text inline from the beginning. Less pretty, but it removes every opportunity for something to silently go wrong.
A browser upload should survive until at least the next turn, so if it fails to be used by Haxgpt right away, I would consider this attachment path broken for now and not contextually consistent. The scope of attachment can be broad, but “forgot it on the next message” is not really a feature.
Another possible scenario is a stale web client. It is possible that your browser caches an old version of the service worker and/or script even after the deployment. Try a hard reload or clearing the site data for Haxgpt and reauthentication. Then, upload a harmless test dummy and ask about the content of the file in the same message. This is different from initiating a new chat since it will use the same cached code as before.
If you are okay with browser developer tools, leave the Network tab open on the upload attempt. If a request there is failed/rejected, that would give us actionable data. In case of a successful upload, but an empty model response, it would indicate the site failed to forward the attachment. You don’t need to read anything there, a red request, authorization error, or simply a payload with the file name would be sufficient to tell us what the problem was.
I would avoid testing with anything sensitive until we sort this out. Haxgpt may show an attachment, but it does not prove the file was processed anywhere beyond the initial upload. If a simple reload reproduces the issue, you can report this to us as an attachment-related client bug, including the browser name, encoding method, and whether the upload request was successful at all. This way, it will be easier to prioritize and debug the context loss scenario.
Don’t treat a successful network request as proof that Haxgpt extracted the text. @silverthinker7366stu’s developer-tools check can confirm transport, but not what happened after the server accepted the file.
Use a controlled two-turn test: attach TXT and ask a specific question whose answer can not be guessed, then send the same question again, but without attaching it. If first one succeeds and second fails, you know the attachment scope is the issue. If both fail, it’s ingestion. If both succeed it’s the original prompt being problematic. Only clear caches once you know what you’re chasing.