Repository navigation
[Bug] chat.z.ai Agent Mode fails to mount/access uploaded files in container workspace (/home/z/my-project/upload/ is empty) #859
Description
Activity
👋 感谢你的反馈，我们已经收到。
- 维护者看到后会尽快回复你。
- 状态保持为
status: 待评估，你可以随时补充信息。 - 信息不全时我们会打上
needs: 更多信息标签并 @ 你。
👋 Thanks — we've received your issue.
- A maintainer will get back to you as soon as we can.
- Status stays at
status: 待评估(Triage); feel free to add context. - If we need more details, we'll add
needs: 更多信息and ping you.
Additional Field Telemetry: Big Prompts Converted to
.txtFail MountingDiscord Reference:
- Source Thread: Discord
#report-a-bugThread 1554265550514028544 - User:
PsychORhythm - Thread Title: "z.ai unable to read .TXT file or BIG PROMPTS"
Symptoms & Critical Nuance:
- Big Prompts Auto-Converted to Files:
- In
chat.z.ai, large pasted text inputs / big prompts are automatically bundled by the frontend into synthetic.txtfile attachments (e.g.Pasted Content_1790635490927.txt). - Because the backend container sandbox fails to mount files into
/home/z/my-project/upload/, even long pasted prompts sent directly in chat fail to reach the agent, reporting:"message didn't arrive on the server / saying the file isn't reached to the server... targeting
/home/z/my-project/upload"
- In
- Blast Radius Impact:
- This expands the severity significantly: it is not only manual file attachments failing to mount, but any long prompt that exceeds inline token length limits and gets auto-converted into a text asset.
- Source Thread: Discord
Additional Field Telemetry: Chinese/Global Multilingual Reproductions
Discord Incident Reference:
- Source Thread: Discord
#report-a-bugThread 1554194871114539078 - User:
JP. - Title: "File upload fails (Agent mode)"
Symptoms & Model Output:
User confirms widespread occurrence across independent accounts:
"So I guess I'm not the only getting this error. When I try to use Agent mode, any file that I try to upload is not actually uploaded."
Model trace shows:
上传的说明文件似乎不在预期路径上。让我更广泛地搜索一下。
The upload folder is empty — the instructions file wasn't delivered. Let me check the current project state and worklog first.This further confirms that this container mounting outage is pervasive across the entire
chat.z.aiAgent Mode deployment, affecting instructions files, prompts, and document uploads alike.- Source Thread: Discord
Same thing is happening here!
With the model GLM 5.3 on agent mode, the agent seems to be able to read the name of uploaded files but, when he goes trough the filesystem to open them, finds them empty.
The issue desn't depend from the kind of file uploaded (I tried with a batch of pdf and then a .zip with no differences whatsoever) and still presents under different OS (MacOS, CachyOS)...
I do not have many competences so I tried to make the agent self analyze... here's what he has found:
------- ai- /home/z/my-project/upload/ is not a normal folder... it's a double mount (idk if it may be useful but I wanted to report that)
- The bug is NOT in the container — the mount works perfectly and is writable. The problem is upstream: your 3 PDFs have never reached the OSS prefix that the container is looking at. The most likely causes:
1: ID/prefix mismatch: the mount is tied to a run UUID (rundoss-918ab1f8-…), while the attachments are associated with session/chat IDs — if the mapping fails, the files end up elsewhere (or nowhere).
2: Race condition: I found that the mounts were created at the exact moment your first message arrived (07:31, ~34min after boot) — if the upload occurs "before" the prefix is ready, the files get lost.
-------- end of ai
Just use this Trick a web (Next js sandbox) with a input type file ask it store that file in the chat files probably inside the z folder . Then upload file in the sandbox preview that file is moved inside the folder eg z/upload/ ... the file is now being stored and can be able to read and accessable by the agent then it works fine. Just use it for upload project files as zip or multiple files compressed [separate files is also fine] as zip make sure you have the proper internet to upload the entire thing before the timeout.
Done ____________________
Now just chat with you agent to access that file and make it work that it. [can be a temporary option before they clear this bug]
Reacted by Daledeis
Bug Description
In the web interface (
chat.z.ai) under Agent Mode, users are unable to have the agent inspect or process uploaded files. Regardless of file format (.pdf,.md,.txt), the backend sandbox/container environment fails to stage or mount the uploaded file into the container filesystem before starting task execution.The agent checks the designated directory
/home/z/my-project/upload/via bash tool calls and confirms the folder is empty:Source & Attribution
@Jason#bad-case-reportThread 1554117850522845356Reproduction Details
chat.z.aiand toggle Agent Mode..pdf,.md,.txt)./home/z/my-project/upload/(or runs search commands likefind / -name "*<filename>*")./home/z/my-project/upload/is completely empty. The frontend shows the file attachment chip, but the backend worker fails to copy or mount the object storage payload into the running sandbox container./home/z/my-project/upload/(or accessible via standard file tools) prior to agent initialization.Technical Hypothesis / Root Cause
The frontend web uploader stores the file asset in temporary blob/S3 storage and links the asset ID to the chat turn payload. However, the container initialization hook responsible for pulling the asset from object storage into the sandbox filesystem (
/home/z/my-project/upload/) is either silently failing, timing out, or missing an authorization token to fetch the blob.