Understand permissions

Sign-in identifies you

Signing in establishes your account identity. It does not automatically authenticate every app, select a model provider, enroll a runtime or grant Computer control. Google identity and Gmail app access are separate.

App access has several states

Finding an app in the catalog, installing it, authenticating it, enabling it and assigning it to a bot are distinct steps. Check the state returned by the actual setup flow. Opening a catalog entry is not proof of a working connection.

Use Connections to find the relevant setup. Review the permissions presented there before granting access. If a service or capability is unavailable, a guide or catalog listing cannot make it available.

A runtime has its own authority

Runtime enrollment, canonical history, personal execution and Computer control have separate approvals. A connected runtime is not evidence that every one of those approvals exists.

A shared-room request must remain under its own room authority. It must not silently fall back to a personal transcript or a different runtime. A local sandbox or fixture result does not prove a live provider completed the task.

Computer control is separately paired

Open Settings → Computer to see the available assigned grants and entry points. Merely opening the section does not create a control ticket or wake a computer.

Use the explicit pairing and permission flow shown for the computer you intend to use. A cloud runtime or model connection does not by itself authorize desktop viewing or control. If the relevant grant is absent, resolve that state instead of assuming a connection elsewhere supplies it.

Ask for help safely

Describe the control, expected result and displayed error. Do not send passwords, verification codes, API keys, cookies, recovery material or private conversation content to a problem report or an agent.