Before connecting a local agent to Skybits, review what the runtime can do on your computer as well as what it can do in Skybits. The two permission boundaries serve different purposes.
An agent may need to read a project folder and create a draft. It may not need permission to run arbitrary commands, inspect unrelated files, or interact with another service signed in on the same machine.
A starting folder is a useful scope cue
Agent Bridge lets you choose a working folder for a profile. Choose a dedicated project area when practical, and keep unrelated confidential material out of it.
The folder alone is not proof of containment. The runtime's sandbox, file permissions, command policy, and connected tools determine its actual reach. Check those settings in the runtime you are using.
A local agent can affect resources available to your user account. Skybits document permissions do not automatically restrict shell commands, local files, or another connector attached to that agent.
Review the profile's approval policy
The current Guide explains that supported runtimes expose different controls. Some distinguish file changes from commands; others map several settings onto one underlying permission mode.
Do not assume a Bridge setting means you will see a prompt every time. The Guide describes automatic allow-or-deny policies in the separate Bridge, and notes that some prerelease profiles may have permissive defaults.
Read the current settings before connecting. If a workflow needs only document work, avoid enabling broader local authority simply to make setup easier.
Understand what crosses the network
The Guide says model-provider credentials remain with the local runtime rather than being sent to Skybits. It separately describes chat messages, replies, tool transcripts, status, and usage information crossing the network.
Content read by an approved tool or included in chat can become part of the conversation. The model itself may be served remotely. Review the local provider account and its data terms.
Local processing and private processing are questions to verify for the actual setup, not labels to infer from the application running on your laptop.
Check reachability in newer desktop builds
The Guide's development-preview desktop section distinguishes Local and Web agents. In Local mode, the agent receives no server schedules or messages from other devices through the server. It can still access Skybits content when asked and use its provider and network connections.
In Web mode, the agent still runs on the computer, but the account can send it work from other devices and server-driven workflows. That changes who or what can initiate activity on a capable local runtime.
This desktop behavior is documented as a preview; confirm availability and terminology in your build. Do not apply it indiscriminately to the separate Agent Bridge app.
Disconnect with a clear purpose
Closing a Bridge window may leave workers running in the tray. Disconnect, Sign out, and Quit have different effects. Use the documented action that matches whether you want to stop work, revoke a deployment's connection, or shut down all profiles.
The Guide also describes persistent credentials using the operating system's credential store and deployments staying separated. On Linux without an appropriate Secret Service, it describes session-only operation rather than insecure disk persistence.
A setup review worth doing once
Check the profile name, runtime, working folder, provider account, document-tool access, local approval policy, and reachability. Recheck after changing the executable or permission policy. Keep your temporary workflow small enough that you can inspect its files and Skybits output.
Next step: Read the Skybits Help. For newer desktop reachability, check the preview section relevant to your installed build.