Hello Dots team and community,
Could you please help route this report to the Dots engineering, permissions, and cloud-computer teams?
I am a Pro user trying to use Dot’s hosted cloud computer for real software development. I appreciate the potential of a persistent assistant that can continue working while my own computer is unavailable. However, three interacting problems have made that workflow difficult to rely on.
I am bringing them together here because related reports already exist in different places. My intention is to add a concrete end-to-end user experience, not to suggest that every symptom necessarily has the same root cause.
Summary
The intended workflow is ordinary development in an existing repository: implement changes, run tests, push a branch, open a PR, review it, and merge it with my authorization.
What happened instead:
- GitHub browser authorization completed, but the cloud CLI still could not establish a usable login.
- A read-only configuration location and unclear filesystem boundaries complicated setup.
- Repeated approvals and troubleshooting consumed hours while additional work remained local and the remote repository did not advance.
A GitHub connector eventually created and merged one specifically approved PR. I want to acknowledge that success clearly: Dot is not entirely read-only, and not every GitHub operation is impossible. The unresolved issue is whether the complete development workflow can be performed consistently and recovered when it breaks.
Why this matters
The official computers-and-apps documentation includes software work among the cloud computer’s uses and describes cloud work continuing while users’ devices are off.
That is the capability I am trying to use. I want to review engineering results without supervising every authentication and execution step. Writing code and running local tests are valuable, but reliably delivering those changes to the repository is also essential.
1. GitHub browser authorization completes, but gh authentication remains blocked
During my November 10, 2026 session:
- I explicitly authorized Dot to use
ghto create and merge a PR. - Dot initiated GitHub’s device authorization flow.
- I completed authorization on GitHub.
- Dot reported that saving the result failed because the default
ghconfiguration location was read-only. - A writable configuration location was selected, and I completed authorization again.
- Dot then reported that access to
api.github.com:443was blocked by policy. CLI authentication was still incomplete.
From the user’s perspective, I had approved the task and completed the requested authentication, yet the operation still could not proceed.
There is a closely matching report, openai/codex #54403, including a reproduction with an explicitly writable GH_CONFIG_DIR.
I had previously used gh successfully in other Dot development workflows. I cannot establish what changed between those sessions and this one. Please help clarify whether this is an intended restriction, a difference between execution environments, or a regression.
Requested clarification: What is the supported, repeatable procedure for authenticated Git operations on Dot’s own cloud computer? How should a user recover when browser authorization succeeds but CLI completion is blocked?
The later connector-based PR merge was a useful alternative, but it did not resolve the cloud CLI failure.
2. Filesystem and configuration boundaries are not clear enough for development
The read-only configuration error raises another practical question: which files and settings can the cloud desktop and the agent’s execution environment actually share?
Another user documented a reproducible discrepancy in openai/codex #50012: a harmless file created in the cloud desktop terminal was not visible to the agent shell, despite matching hostname and user identity.
I have not independently reproduced that full test. In my own case, the direct symptom was the reported inability to write the default CLI configuration location. Whether these cases share a cause needs engineering verification.
For a developer, these boundaries affect much more than convenience. Installing or authorizing a tool through one interface does not complete setup if the agent cannot use the resulting configuration.
It would help greatly to have a clear explanation of:
- Which filesystem locations are shared between the desktop and agent execution.
- Where supported CLI configuration should be stored.
- What state survives task changes, restarts, or instance replacement.
- How users and the agent can identify the environment currently executing a command.
Requested improvement: Please document and expose these boundaries before setup, rather than requiring users to discover them through failed authentication attempts.
3. Repeated approvals do not reliably translate into completed work
I explicitly approved repository work and later approved a concrete change set. Nevertheless, the workflow involved repeated approval and troubleshooting exchanges. For several hours, progress reports continued to reference the same merged repository state while additional work remained local.
The agent also made avoidable mistakes in diagnosing the environment and communicating progress. I do not want to attribute every delay to infrastructure. But users need a way to distinguish an agent mistake from an authentication problem, an approval that was not applied, or an execution restriction that approval cannot change.
A related community discussion, “Dot: repeated approvals and unexplained 403s make authorized tasks unusable”, describes approvals followed by unexplained denials. The 403 symptom belongs to that report; I am not presenting it as the exact error from my gh attempt.
Requested improvement: When an approved action remains blocked, please give both the user and Dot an actionable explanation:
- Is approval missing, expired, or inapplicable?
- Did authentication, filesystem access, network policy, or another restriction fail?
- Can the user resolve it? If so, what exact supported action is needed?
- If it cannot be resolved by the user, what alternative is supported?
- Can support receive a diagnostic reference without requiring credentials or private source code?
This would prevent repeated approval requests from becoming a troubleshooting loop.
The combined impact
An authorization can appear successful to the user, fail when configuration is saved, and fail again at network access. A connector may work while the CLI does not. Local implementation may continue, but the repository remains unchanged.
The result is that I spend time supervising the environment instead of reviewing the product being built. That substantially reduces the practical value of an autonomous cloud development assistant.
I understand that security controls and isolation are necessary. I am asking for predictable behavior, clear boundaries, and a documented recovery path within those controls.
What would help resolve this report
Could the relevant teams please:
- Triage these three areas together and link this report to the existing issues where appropriate.
- Clarify which observed behaviors are intentional restrictions and which are defects under investigation.
- Provide a tested cloud-only workflow covering repository access, CLI authentication, implementation, tests, push, PR creation, and merge.
- Document filesystem/configuration persistence and provide actionable denial diagnostics.
- Test the workflow across fresh tasks or resumed sessions, not only within one successful setup session.
If a separate Codex cloud environment is required for some steps, please explain that boundary, its setup requirements, and how work already on the Dot computer is meant to continue there.
I am deliberately consolidating the existing discussions because the end-to-end experience is the important part: can an authorized user depend on Dot to finish an ordinary development task on its cloud computer?
Thank you for taking the time to review this. An indication of the responsible team and a concrete supported next step would be very helpful.
No credentials, authorization codes, private repository contents, or financial data are included.