Cloud tasks can be launched and supervised not only from a work machine: there is a native application for phone and tablet, a web interface and, on other platforms, a web app through the browser. A conversation from the terminal is handed to the cloud with a special prefix and then opened on any of those surfaces. The convenience is obvious: the task keeps running while you are on the move, and the result waits for you not in a closed laptop but in a shared place you can look into from any device.
But distributed access has a second side - identity. A link to an agent can be sent to a colleague, and that looks like an ordinary exchange of links. In fact visibility requires membership in the same team and your own access to the repository through the connected version control system, while the default view is read-only. A link does not widen rights: it shows exactly what the person was already entitled to see. That is correct behavior, and it is worth understanding before you try to share one.
Follow-ups to someone else's task are a separate mechanism enabled by an administrator with three states: disabled, service accounts only and everyone. The difference between them is much larger than the wording suggests. A follow-up runs with the creator's original credentials and secrets: the person who added a message steers a process that acts on your behalf and with your rights. The provider's logs will keep your account, even though the direction of the work was set by another member of the team.
That is why the everyone option is enabled not by default but after a deliberate look at the threat model. It is convenient in a small trusted team where everyone already has the same access, and dangerous in a large organization, where the right to continue someone else's task means the right to use someone else's access - including to repositories and secrets not open to that person at all. The middle option, where follow-ups are allowed only for service accounts, is usually the right compromise: they have narrow rights, and narrowing them further costs nothing.
Hence a general principle worth keeping in mind for any team work with agents: sharing a result is not the same as sharing access. A link to a conversation, an artifact or a pull request shows the result. The right to continue the work transfers authority. Those two actions often look identical in the interface - the same page, the same button for copying a link - and are built completely differently in the security model. Confusing the two meanings is what produces most of the unexpected access channels.
| Action | What it transfers |
|---|---|
| A link to an agent | Visibility given team membership and your own repository access |
| The default view | Read-only |
| A follow-up to someone else's task | Authority: the creator's original credentials and secrets |
| A service account | Narrow rights suitable for shared automations |
It is also worth understanding what exactly moves when a conversation is handed from the terminal to the cloud. What moves is not a window but the execution: from there the work runs in the cloud environment, with its own repositories, secrets and network mode, rather than on your machine. That is precisely why the task becomes visible on other surfaces - it is no longer tied to a particular computer. The flip side is the same: local state, uncommitted edits and your machine's settings do not follow it, and counting on them after the hand-off is not an option.
The mobile surface adds its own nuance: it is convenient for approvals and short clarifications but poorly suited to judging changes. A phone screen shows a few lines, while a merge decision requires seeing the change as a whole and the surrounding code it touches. The temptation to confirm on the go arises exactly where confirmation requires attention. A sensible practice is to read, steer and if necessary stop from the phone, and to make merge decisions where you can actually look at the changes.
A service account solves not only the question of rights but the question of ownership. A shared automation launched from a personal profile inherits one person's access and breaks the day that person leaves or changes roles. A separate account with narrow rights makes the process independent of staffing moves and also simplifies analysis afterwards: it is visible that the action was taken by a process, not by an employee. The sign by which this is usually noticed in real work is simple: a colleague writes that the link does not open. That is not a breakage but a working access model - the person lacks either team membership or rights to the repository.
The engineering conclusion is simple: remote access is good for observation and short decisions, while authority remains a matter of settings rather than convenience. Separate three things - visibility, the right to continue and the account's rights - and team work with cloud agents will stop creating unexpected access channels. Each of the three is configured separately, and none of them is cancelled by the convenience of the interface.
The typical failures are predictable. Believing a shared link gives a colleague access, or conversely that it is safe regardless of settings. Enabling follow-ups for everyone without working out whose credentials are used. Approving a merge from a phone without looking at the changes. Counting on local machine state after the hand-off to the cloud. And using a personal account where a service one is needed.