Runtime connections and pairing
The runtime listens on loopback by default, so its default address is local to the computer running it. Network access is an explicit hosting choice, such as starting the CLI with --lan. See runtime configuration before exposing a runtime to a network.
Owner pairing creates a session token. The runtime stores a hash of that token and issues an HttpOnly, SameSite cookie; browser reconnect also keeps the token in session storage. Treat the pairing code and session credentials as secrets.
Access grants control file reads and writes, collaboration, terminals, tasks, Git, language services, and extension operations separately. Grants are revocable. Revoking a grant closes its connections and terminates processes owned by that grant.
Workspace trust and code execution
Tool trust is a separate workspace decision from pairing and access grants. Selecting Trust workspace tools enables tools such as terminals, tasks, Git, and language services. Revoking workspace trust terminates workspace tools.
Terminal and task commands run with the runtime user's operating-system privileges. Git hooks and language-server tools can execute workspace code. The runtime owner is responsible for that operating-system account and its credentials.
Trusted extensions share the browser or runtime process that loads them. Extension capability declarations do not sandbox JavaScript in that process. Trusted extensions and workspace commands do not have sandbox isolation.
Collaboration is off by default and can be enabled in Extensions. Sharing a workspace creates revocable grants; consider both the access you grant and the tool trust enabled for that workspace.
AI providers and connected services
AI agents send prompts, conversation content, and workspace data they read to the model service you select. Oxbit supports provider and endpoint choices, including OpenAI, Anthropic, and OpenAI-compatible services. External agents and extensions use their configured services.
Those services handle received data under their own policies. Review the Oxbit privacy policy for device storage, credentials, connections, and optional services.
Saves, drafts, and connection recovery
Runtime file saves compare disk revisions before writing and use an atomic rename. A changed file produces a conflict instead of silently treating an old revision as current. Browser directory writes also check revisions, but an external change between the check and commit can be overwritten.
Draft recovery stores document state in browser storage. Failed saves, missing files, and permission errors preserve draft content. Closing the browser before a pending storage update finishes can lose the final unpersisted change.
After a connection loss, surviving terminal sessions can reattach. If the runtime process stops, its terminals stop too. Recovery checks the status of commands or commits with uncertain outcomes and does not automatically run them again.
Read documents and recovery for save conflicts and storage limits, and trust and recovery boundaries for technical details.
Report a vulnerability privately
Email ryanyannelli@gmail.com. Keep undisclosed vulnerabilities out of public issues, as described in the published reporting policy.
Include:
- The affected version or commit and operating system.
- Steps to reproduce and the security impact.
- A minimal example or relevant logs with credentials and personal data removed.
For ordinary bugs and setup questions, visit support.