[Bug] chat.z.ai agent: uploaded files never land at /home/z/my-project/upload/ AND agent workspace is silently cleared between turns

提交前确认 · Pre-submission checklist

• 我已搜索过现有 issue，确认这不是重复 / I searched existing issues and confirmed this isn't a duplicate.
• 我已阅读 CONTRIBUTING.md / I've read CONTRIBUTING.md.

问题类别 · Category

文件操作 · File Operations

涉及的 Agent 框架 · Agent framework

不涉及框架 · Not framework-specific

严重程度 · Severity

阻塞使用 · Blocking (无法使用核心功能 / core function unusable)

复现频率 · Reproducibility

必现 · Always

问题描述 · Description

The chat.z.ai built-in agent (the one running in the sandboxed workspace at /home/z/my-project/) exhibits two related defects that together make file uploads effectively unusable:

1. Agent reports its workspace was cleared. Mid-conversation, the agent claims that its working directory has been reset / cleared — previously-referenced files and prior artifacts are no longer present where the agent expects them. This is not a user-initiated reset; it happens silently from the user's perspective.

2. Uploaded files never land on the filesystem. When a user uploads a file via the chat.z.ai attachment UI, the IM gateway reports the upload as successful (UI shows the file attached to the outgoing message), but the file is not actually present at /home/z/my-project/upload/. The upload folder is empty. The agent then correctly reports it cannot find / read the uploaded file — because the file genuinely isn't there.

A representative environment-side log line from the agent itself:

⚠️ Environment bug notice: The file you uploaded is not present at /home/z/my-project/upload/ despite the IM gateway reporting it as uploaded. The upload didn't actually land on the filesystem — the upload folder is empty.

Combined effect: the user uploads a file expecting the agent to read it, the agent instead tells the user the workspace was cleared / the file is missing, and the user is left unable to use the chat.z.ai agent for any task that depends on file input (code review, log triage, screenshot analysis, document Q&A, etc.).

复现步骤 · Steps to reproduce

1. Open a new conversation on chat.z.ai.
2. Establish some workspace state — e.g. ask the agent to create a file, write some content, or run a small script that produces output under /home/z/my-project/.
3. In a follow-up turn, attach a file via the chat input's attachment button (e.g. a screenshot, log file, or PDF).
4. Send a message asking the agent to read / analyze the attached file.
5. Observe that the agent:
   • either reports that its workspace was cleared / previous artifacts are gone, and/or
   • reports that it cannot find the uploaded file at the expected path (/home/z/my-project/upload/<filename>).
6. Inspect the agent's environment (e.g. ask it to ls -la /home/z/my-project/upload/) — the directory is empty or the uploaded file is not present, despite the UI showing the attachment as successfully uploaded.

期望表现 · Expected behavior

• Uploaded files should reliably land at /home/z/my-project/upload/<filename> inside the agent sandbox, with the same filename the user attached.
• The agent's workspace state should persist for the lifetime of the conversation — files the agent created in prior turns should remain accessible in subsequent turns.
• If an upload fails for any reason (size limit, virus scan, etc.), the UI should show an explicit error on the attachment itself, not silently report success while the file is missing on the backend.
• The agent should never have to tell the user "I can't find your file" or "my workspace was cleared" as a result of an infrastructure defect.

实际表现 · Actual behavior

• The IM gateway returns a success response for the upload, the chat UI shows the file attached to the outgoing message, but the file does not exist at /home/z/my-project/upload/.
• The agent's workspace appears to be cleared / reset between turns in some cases, losing prior state.
• The agent correctly diagnoses the missing file (it really isn't there) but the user perceives this as an agent failure rather than an infrastructure failure.

ZCode 版本 · ZCode version

N/A — this is the chat.z.ai web agent, not the ZCode desktop / CLI client.

设备 / 系统 / 浏览器 · Device / OS / Browser

• Platform: chat.z.ai (web)
• Browser: any (reproduced across browsers)
• Account region: any

截图 / 录屏 / 日志 · Screenshots / Recordings / Logs

Reporter-provided environment-side log line:

⚠️ Environment bug notice: The file you uploaded is not present at /home/z/my-project/upload/
despite the IM gateway reporting it as uploaded. The upload didn't actually land on the
filesystem — the upload folder is empty.

Reported via Discord

• Reporter: rousevv
• Channel: https://discordapp.com/channels/1346756824233148527/1531306147104161802
• Note: this is a Discord channel link (no message ID). This bug was reported through the public Discord support channel because there is currently no private helpdesk (see #125). The reporter had to disclose an infrastructure failure in a public channel — exactly the privacy problem #125 describes.

Likely root cause (hypothesis)

Two separate but possibly related defects:

1. Upload pipeline broken between gateway and sandbox. The IM gateway accepts the upload, stores it (or claims to), and returns success to the UI — but the actual copy / mount / sync into the agent's sandbox filesystem at /home/z/my-project/upload/ is failing silently. Possible causes:

   • Sandbox volume mount is read-only or full.
   • Upload handler is writing to a different path than the sandbox expects.
   • Asynchronous copy job that's failing without surfacing the error.
   • Sandbox is being recycled / replaced between the upload and the agent's read (which would also explain the "workspace cleared" symptom).

2. Workspace not persisting across turns. If the agent sandbox is being recreated per-turn (e.g. for security isolation), then any file the agent writes to /home/z/my-project/ is lost on the next turn. This is consistent with the "workspace got cleared" report and would also explain why uploaded files don't survive — they're written to a sandbox instance that's replaced before the agent reads them.

Suggested debugging angle:

1. Verify the upload path: after a successful upload from the UI, immediately ls -la /home/z/my-project/upload/ from the agent — confirm the file is missing.
2. Check whether the sandbox filesystem persists across turns within the same conversation. Write a file in turn 1, then ls it in turn 2 — if it's gone, that confirms the per-turn sandbox reset hypothesis.
3. Inspect the IM gateway logs for the upload — see if there's a silent error on the file-copy / mount step.

Why this matters

• Core functionality broken. File upload is a fundamental feature of any AI chat product. If it silently fails, every workflow that depends on it (code review, document analysis, log triage, screenshot reading, PDF Q&A) is broken — and the user doesn't even know it's broken until the agent tells them.
• User trust. When the agent says "I can't find your file" or "my workspace was cleared," the user doesn't know whether to blame the agent, the upload, or themselves. The defect manifests as a confused, unhelpful AI rather than what it actually is — an infrastructure failure.
• Discord-only reporting problem. The reporter had no private channel to file this in (per #125), so the failure mode itself is being disclosed publicly. Each infrastructure bug reported via Discord is also a small PII leak.

Related

• #125 — Private helpdesk / support ticketing system. This bug was reported via the public Discord channel because there's no private alternative. The fact that an infrastructure failure of this severity had to be surfaced in a public forum is itself a symptom of #125.
• #123 — Customer portal 5H next reset shows date only. Same theme: the chat.z.ai / customer portal stack has multiple silent-failure points where the UI reports success while the backend is in a degraded state.
• #130 — ZCode OAuth login shows only 2 models. Same family: silent degradation with no user-visible error. Both this bug and #130 are cases where the user only discovers something is wrong when the agent (or model picker) fails to do what was expected, with no prior warning.

---

Regards,
Roman
http://www.rommark.dev
VIbe Coders Telegram Channel: https://t.me/VibeCodePrompterSystem

No repository files, tests, or implementation entry points are named. Start by reproducing the upload and cross-turn persistence checks described in the issue, then inspect the IM gateway and sandbox handoff; done means uploaded files appear at /home/z/my-project/upload/ and workspace files persist between turns, with failures surfaced to the UI.