What agents can see and do
Agent access depends on the request, channel, tools and permissions; profiles show only part of the access record.
An agent’s access depends on its configuration and request. The configured tools, workspace policy, channel and requesting person’s permissions constrain each operation. A profile’s permissions section supplies only part of its access record.
What an agent reads
A direct request can include previous messages supplied to the agent. Channel requests use the channel’s context. Content in a conversation can contain confidential material, even when the request asks for a public answer. A message to an agent grants no access to connected repositories or documents.
| Boundary | Meaning |
|---|---|
| Role | A description of intended work, without an access grant. |
| Channel | The conversation and scope for channel-related operations. |
| Tool | An operation admitted by configuration and policy. |
| Requesting person | A permission boundary for agent operations. |
Tools and permissions
Public web search can be available to an agent when workspace policy permits it. Private context restricts search during a tool-assisted turn. A request to search can therefore finish without a search result.
Tool availability varies within each tool family. Repository changes, document writes and terminal operations require their own tools and access. The result of an operation supplies evidence beyond the reply.
A channel mention constrains channel-related operations to that channel. A direct message preserves the requesting person’s permission checks. An agent role grants no additional authority.
Engines and authentication
A role name and an engine name describe different things. The Project Sessions list recognises Claude, Codex and OpenCode sessions running in terminals. Each row identifies an engine and its terminal; it makes no claim about the task underway. Other engine names can appear in usage displays without establishing that this list can discover their sessions.
Signing in to the application is separate from authenticating an engine with its provider. An engine needs its own configured account or credentials before it can carry out provider-backed work. The profile offers no engine sign-in or credential editor. The provider’s account, available models and limits determine the options for that engine.
Approvals and shared work
An approval request identifies an operation requiring a decision. Permission to answer a conversation is separate from permission to approve an operation. A review finding is separate from a provider’s review verdict or merge authorisation. Joining a channel creates no universal human approval gate.
A document edit and a document suggestion have different effects. A saved edit changes the document; a suggestion awaits acceptance or rejection. Agent authorship alone leaves the mechanism unspecified.
Interruption and recovery
Stop interrupts a running reply for the person it answers or a channel manager. Completed tool operations remain after a successful stop. Stop not confirmed means confirmation of the stop has yet to arrive. Retry and Regenerate produce another reply associated with the original. A reply already regenerated offers navigation to its replacement.
Profile limits
A profile can show identity, model information and a cordon notice. The profile offers no cordon control. Its current runtime data can omit instances, assignments, permissions and tool access. An empty list leaves past activity unknown. A zero aggregate cost alongside no instances leaves the actual cost unknown.