ChatGPT dot cloud computer: GUI terminal and agent shell see different HOME files on the same instance #50012

What issue are you seeing?

In the ChatGPT dot cloud computer, a harmless file created in the desktop GUI terminal is immediately invisible to the agent's shell, even though both report the same hostname and user (UID 1000).

This report concerns the hosted dot computer, not my Windows PC. I am reporting this as a possible bug or an undocumented isolation boundary, rather than assuming that sandboxing itself is incorrect.

What steps can reproduce the bug?

1. Open the terminal in the dot's cloud desktop.
2. Create a harmless, empty diagnostic file and verify it exists:

touch /home/agent/cora-repro-marker.txt
ls -l /home/agent/cora-repro-marker.txt
hostname
id -u

3. Ask the dot to inspect that same file using its command-execution shell:

ls -l /home/agent/cora-repro-marker.txt
hostname
id -u
findmnt -T /home/agent -o TARGET,FSTYPE,OPTIONS --noheadings

4. Compare the results without restarting either surface.

Observed on October 1, 2026, approximately 15:42 UTC:

• The GUI terminal lists the zero-byte file, owned by agent.
• The agent shell returns No such file or directory for exactly that path.
• Both surfaces show the same hostname and UID 1000.
• The agent shell mounts /home/agent as read-only tmpfs.
• The task workspace is available as a writable overlay.

Sanitized output from the agent shell:

1000
ls: cannot access '/home/agent/cora-repro-marker.txt': No such file or directory
/home/agent tmpfs ro,nosuid,nodev,relatime,mode=755,uid=1000,gid=1000

The marker contains no credentials or personal data.

What is the expected behavior?

Either a non-secret file created through the cloud desktop should be accessible through the corresponding authorized agent workflow, or the UI/documentation should clearly explain the separate filesystem views and provide a supported way to use user-created files and CLI configuration across these surfaces.

I am not requesting weaker sandbox protections or automatic access to credentials.

Additional information

Practical impact: I completed a CLI browser-authorization flow in the cloud GUI terminal. The terminal showed a successful welcome message, and a subsequent identity check in that same terminal succeeded. However, the agent's shell could not see the saved default configuration and stopped locally with:

mkdir /home/agent/.doppler: read-only file system

This led to repeated setup troubleshooting despite the browser authorization already having succeeded. The empty-file reproduction above isolates the filesystem mismatch without requiring any real login.

Separate persistence observation: Later, the cloud hostname changed. Application files in the task workspace remained available, but the prior CLI configuration directory was absent even from the new GUI terminal. I did not initiate a reset, and the exact lifecycle trigger is unknown. I cannot establish whether this reflects intended retention boundaries, an instance-replacement issue, or another cause.

Related: #49682 already covers cloud-computer persistence and instance changes; #49821 was closed as its duplicate. This issue focuses on the reproducible simultaneous GUI-versus-agent HOME visibility mismatch. Please consolidate it with #49682 if it belongs to the same underlying issue.

Official computers-and-apps documentation describes retained computer state, but I could not establish a directory-level persistence or cross-surface visibility contract.

An earlier command not found was caused by a workspace-local CLI installation not being on PATH. That was our setup issue and is not included as a product defect here.

Questions:

• Is the separate HOME filesystem view intentional?
• What is the supported workflow for files/configuration created by the user in the dot cloud desktop?
• Which directories and login/configuration state are expected to survive cloud instance replacement?

Environment: ChatGPT dot cloud computer, Linux desktop/terminal, accessed from ChatGPT web on Windows. Exact hosted runtime/product build was not available to me.

No credentials, authorization codes, bank information, private repository details, or screenshots containing authentication information are included.

Reported by Jessé Varjão (@Beowulfwar).