Cloud agents now ask for tool permission in your terminal, marked as remote, with no "always allow" option.
What's wrong with this entry?
An agent running in a cloud session now sends its tool requests back to your local machine, so you approve or deny each one in the usual prompt instead of the remote run stalling or failing. These requests always reach you: the permission classifier that normally auto-approves routine tools is skipped for anything a remote agent proposes, and the dialog marks the origin with "from a remote cloud agent". Answers you give a remote agent never offer the "always allow" option, so nothing a cloud agent asks for can quietly become a standing rule.
- The Agent tool hands the relay the local approval callback, the local tool context, and the set of tool names that agent is permitted to use.
- Remote origin is now a third reason to bypass classifier auto-approval, alongside the existing checks for requests the classifier cannot approve and for an organisation policy that limits what may be asked.
- At most 8 requests are in flight at once, and requests are debounced by 1200ms.
- A request is refused rather than forwarded when the tool is not in that agent's permitted set (
tool_not_in_agent_pool), when answering would need interaction the remote side cannot provide (requires_user_interaction), when it is a privilege escalation (escalated_ask), or when the in-flight cap is reached (too_many_pending). - Outcomes are recorded as
tengu_remote_agent_permission_forwardedandtengu_remote_agent_permission_fallback. - Two separate points in the permission flow check for a remote origin and skip the branch that would create a persistent allow rule.
- The relay has no feature flag or setting; it is active wherever a cloud agent is launched.
tengu_remote_agent_permission_forwarded, from a remote cloud agent
Strings lifted out of the shipped bundle, so the claim above can be checked against them.