[BUG] Projects: shared folder (/mnt/project-files) fails with EIO on every operation exactly 24 hours after the container's mount starts, and never recovers

Where: a thread session in a claude.ai Project running in a Claude Code cloud container. The project's shared folder is mounted at /mnt/project-files → /mnt/attach/project-files (fuse.rclone, served by rclone-filestore multimount).

Summary: 24 hours after the mount process starts, every operation on the shared folder starts failing with Input/output error, and it never recovers for the rest of that container's life. Containers that get replaced in under a day never notice; any container that stays up longer than that loses the folder.

Reproduction (2026-10-01)

I kept one container busy and checked the folder every 10 minutes, with an hourly write that I confirmed had finished uploading.

• rclone-filestore multimount started at 2026-09-30 22:12:29 UTC.
• The last successful check was at 2026-10-01 22:07:34 UTC (23h55m later).
• Every check from 22:17:34 UTC (24h05m) onwards failed, reads and writes alike:

$ ls /mnt/project-files/
ls: reading directory '/mnt/project-files/': Input/output error
$ stat /mnt/project-files/<any existing file>
stat: cannot statx '...': Input/output error
$ echo test > /mnt/project-files/.probe/new
sh: 1: cannot create /mnt/project-files/.probe/new: Input/output error

• The mount is still listed in mount, df still succeeds, and the mount process is still alive.
• Errors come back immediately; nothing hangs, and it's never ENOTCONN.
• The session has no way to remount, and retrying doesn't help. It was still failing 50 minutes later, when the platform replaced the container.
• A previous container in the same session lived 22h18m with no errors before the platform replaced it, which fits the 24-hour boundary.

First seen: in another thread of the same project, whose container ran from about 2026-09-27 18:09 UTC for about 51 hours. The folder worked at first, and from its next use at 2026-09-28 22:08 UTC every operation failed the same way until the container was replaced on 2026-09-29.

Likely cause: the credential the mount is started with lasts 24 hours and is never refreshed. That's an inference from the timing: rclone's log isn't visible from inside the container.

Impact: the shared folder is where Projects threads keep work that must outlive the container, so a long-running thread quietly loses its backups, and scripts that fall back on errors turn it into silent data loss.

Expected: the mount keeps working for as long as the container lives (refresh the credential, or remount). Failing that, a clear signal to the session that the shared folder is unavailable, instead of a generic EIO.

Smaller, separate issue (healthy mount, reproducible): rmdir of an empty subdirectory right after renaming its parent fails with EIO, then succeeds a few seconds later:

$ mkdir -p a/b/c && mv a a2 && rmdir a2/b/c
rmdir: failed to remove 'a2/b/c': Input/output error

IDs for log lookup

• Reproduction session: session_01WxbZbnpjcnhikwGqrqqveY
• First occurrence session: session_01KNCBDskeQ6VNLezT6QtiDe
• Shared folder filesystem: pjfs_01X5nhzhkt3UNDHCvNPDB7De

---
_Generated by Claude Code_