CLAWPOD ENGINEERING
Decide Who May View an Agent Desktop Before Sharing It
Set viewers, password ownership, and sharing scope before opening Agent Desktop. Separate Portal surfaces and conversation records without assuming unverified permission or audit controls.

This guide is for operations staff preparing to share an Agent screen in a meeting. It explains how to decide who may view it, who manages its password, and what may be shared. You need access to information about the target Agent and your organization’s access policy. This is an operational decision guide, not a button-by-button tutorial.
Decide who may view the screen first
Agent Desktop is the graphical workspace of the environment where an Agent runs. It may expose files, a browser, and signed-in screens, so viewing alone can disclose information even when you issue no instructions. The official Guide advises accessing only the targets your work requires and excluding sensitive information from screen sharing and recording.
Settle three questions first: who may open the screen and for what purpose, who manages the password, and what must not be shared or recorded. Writing a person’s name in a document is not the same as granting or revoking actual access. The responsible person must verify access through the organization’s approved administration process.
This article covers the Agent runtime viewed through the ClawPod Cloud Portal. It does not mean your laptop or a separately connected computer. Connecting an external computer and configuring its operating-system permissions are separate tasks; do not apply the Portal Desktop instructions to them unchanged. Nor should you treat Portal access policy as the same thing as settings inside the Agent Control UI.
Separate Desktop, Dashboard, and conversation records
The official Guide says that Desktop, Dashboard, and Conversations may appear on an Agent’s detail page. Each gives you a different view. A Room is a shared conversation space for users and Agents.
| What you need to inspect | Surface | Do not confuse it with |
|---|---|---|
| The Agent runtime’s graphical workspace | Desktop | A separately connected personal computer |
| The Agent’s control interface | Dashboard | The Desktop’s files and application windows |
| Recent conversations in Rooms the Agent joined | Conversations | Chat, where you send work requests |
Dashboard means the Agent’s control interface. The Guide describes its use on an Agent in the running state, embedded in the Portal or opened in a separate tab. Apply the same information-protection rules when sharing a new tab or a fullscreen view. This article does not describe current Portal button positions or the Agent Control UI’s detailed features.
Desktop requires a running Agent with a full runtime image that supports a graphical desktop. In the Guide, a full image is a runtime with a browser and graphical desktop, while a lite image is a lightweight runtime. Lite does not include Chromium, a graphical desktop, or VNC/noVNC components. VNC/noVNC are components used to display a remote desktop.
The Guide describes browser work on a full image and command-line work on either a full or lite image. It does not provide a full/lite selector in the ordinary creation flow. The platform super administrator controls image selection, and an available full image is selected by default for ordinary users. If the desktop you need is not ready, tell the administrator which Agent and task require it.
A password change affects the connection
The Guide says that the Portal manages a VNC password per Agent and displays whether it is set, not its value, on the viewing screen. Do not put the password in Chat or instruction files such as SOUL.md and AGENTS.md. Record its status, the person responsible for a change, and the change date. Keep the value itself in your organization’s approved secret-handling process.
The person performing setup or a change must have confirmed password-management authority and approval for the action. According to the Guide, a password change starts an Agent restart, and the viewer loads a new connection about eight seconds later. This is documented reconnect behavior, not a recovery time measured in your current environment or a guarantee that the connection will succeed. Check the impact on ongoing work and announce the change window.
The Guide warns that removal of an existing password has not been confirmed, so do not use removal as a way to return to passwordless VNC. Do not remove or change the password blindly to troubleshoot a connection.
Fill in three lines before sharing
The following are operating rules for your organization to decide. They are not a claim that the product enforces those rules automatically.
| Decision | What to record | What to verify |
|---|---|---|
| Viewers | Work purpose, owner and deputy, access end time | Approved viewers match actual access |
| Password management | Setup/change owner and change-record location | You can tell who changed it and when without recording the value |
| Sharing and recording | Material to share, prohibited screens, recording permission | Files, signed-in screens, and personal information are not exposed |
Illustrative decision example: An operations owner wants to show an Agent’s work in a meeting. Initially, sharing the entire Desktop seems sufficient. A check reveals that the browser has a signed-in business page open, and some attendees are not authorized to view that material. Minji is designated as the screen-access owner and Junho as the deputy; a separate administrator handles password changes. For this meeting, the team decides to share only a reviewed, nonsensitive result document, with no Desktop sharing or recording.
Success is not simply opening the screen. It means the material matches the audience’s access and no sensitive screen was exposed. If the material’s sensitivity or an attendee’s authorization is unclear, hold the sharing step and ask the information owner. If exposure has already occurred, follow your organization’s incident-response and record-retention procedures. Do not assume deleting a recording later resolves the incident.
Separate task conditions do not prove separate permission controls
The Guide’s capability catalog lists conditions for Agent management, organization/user/policy management, cost information, and audit-record access. These are useful when assigning responsibilities. They do not prove that the product provides a specific Desktop-viewer role or independently configurable permission for every screen.
Likewise, the existence of audit-record access does not establish that every Desktop opening is recorded. Ask the administrator whether the viewing events you need are actually collected, who can read them, and how long they are retained. This article does not guarantee Desktop-viewing audit coverage or describe per-role permission configuration.
Separate connection diagnosis from sending instructions
For the Dashboard connection, the Guide says the Portal’s server-side proxy passes the Gateway token to the Agent, so users do not enter it. If the Agent is awaiting_auth, complete the authentication guidance first. Distinguish an environment-not-ready notice from a connection error when reporting the problem. The Guide describes the Portal reloading at most twice before displaying a Gateway connection error; this is not an instruction to keep retrying manually.
The Guide says the Desktop viewer can show a connection error if noVNC/websockify components are not running or the runtime cannot be reached. The error alone does not prove a password problem. Share the Agent state, the surface that failed, and a nonsensitive error summary—not passwords, cookies, or entire logs. Do not report work as complete when the environment is not ready.
Conversations is a read-only conversation record. The Guide describes Rooms the Agent joined as grouped into user-participating and Agent-only Rooms, with the latest 100 messages in the selected Room refreshed every 10 seconds. These are documented values, not a measurement of current display latency. You cannot send messages or edit a Room there. Send work instructions in Chat by opening a Room the target Agent joined.
Before scheduling the next screen share, fill in the viewers, password owner, and sharing scope for one target Agent using the table above. If any item remains unconfirmed, ask the responsible person before sharing the screen.
Sources
- ClawPod Guide — Viewing the Agent Desktop and Conversations: runtime requirements, password changes and connection errors, read-only conversation records, and sharing precautions.
- ClawPod Guide — Asking an Agent for Browser and CLI Work: runtime image conditions, requests in Chat, and handling sensitive information.
- ClawPod Guide — Capability Overview: task prerequisites, not a guarantee of specific roles or complete Desktop-viewing audit coverage.


