User documentation

Glixo Code user guide

Glixo Code is a cross-device agentic coding app. You choose a project, connect a model provider, start a session, and let the agent read files, edit code, run commands, and explain what changed. You stay in control through permission prompts, review surfaces, checkpoints, and notifications.

Install and sign in

1. Open Downloads. The page reads the latest stable release index and shows compatible Windows, Linux, macOS, and Android packages for the same release train.
2. On Windows, use the normal Setup.exe installer. Advanced users can use the portable ZIP.
3. On Linux, download the AppImage, make it executable, and run it. It is the native desktop app and receives in-app updates.
4. On macOS, download and run the pkg package. The package starts the local runtime without assuming the installer is running inside your interactive desktop session.
5. On Android, download the APK from the same page, install it, and approve the browser or system install prompt if Android asks for confirmation.
6. Launch Glixo Code and sign in with your Glixo account.
7. Choose how the agent should run: use the browser sandbox for zero-install work, or connect a desktop target machine for full local filesystem and terminal access.
8. Open Settings - LLM Providers and add at least one LLM provider account.

The browser sandbox keeps setup light: it can use terminal, files, git, and app preview in a cached WebAssembly Linux environment. A connected target machine is better when the agent needs your real repository, native tools, local apps, or desktop integration.

The stable Downloads page is the supported customer install path. Dev-channel manifests are linked for testers, but normal users should stay on the stable installer and APK unless a maintainer asks them to test a dev build.

Choose a target

glixo.ai runs the public browser version of Glixo Code. Choose the browser target when you want zero installation: the page loads a WebAssembly Linux image and keeps the work in the browser sandbox. Choose a local machine when you want Glixo Code to use your real filesystem, terminal, desktop apps, and native tools; in that case install the desktop app and use that machine as the host.

Agxos is the visual OS surface inside Glixo Code. In browser-sandbox sessions it uses the already-loaded browser image. In local-machine sessions it does not start WebAssembly; it uses the same local machine target as the session. Standalone demo links at os.glixo.dev use the full browser image, while mini.os.glixo.dev uses a lightweight demo image for marketplace embeds.

Browse user-facing extensions at extend.glixo.io. Extension authors use glixo.dev and docs.glixo.dev.

Add model providers

Provider accounts are scoped credentials used by agent sessions. Provider ids stay stable, but the add-account screen uses plain labels so the choice is obvious:

OpenAI, Anthropic, OpenAI browser login, and Ollama ship as bundled LLM providers. CLIProxy is first-party but installable from the extension catalog. OneDrive and Dropbox are installable storage providers, not bundled providers.

Add storage providers

OneDrive and Dropbox are optional community storage modules. Install one from Extension Catalog, then open Settings - Storage and connect the account with browser sign-in. Glixo owns the OAuth callback and token storage; the provider module only declares metadata, scopes, and capabilities.

• Inline is the default attachment mode. Files stay in Glixo and the runtime injects supported content into the LLM request.
• Cloud link uploads the attachment to the selected storage provider, asks for a short-lived raw download URL, probes that URL, then sends the URL to the LLM provider. If the provider is missing or the probe fails, Glixo falls back to inline.
• P2P replication stays enabled for paired devices. No cloud storage provider is required for live paired-device sync.
• Cloud replication is disabled by default. Enable it in Settings - Storage and choose a connected provider that advertises the Replication capability when you want resume bundles stored in OneDrive, Dropbox, or another future storage provider.

Settings - Storage also checks the extension catalog and shows how many installable storage providers advertise replication and public-link capabilities, so you can tell whether more providers are available before installing them.

Managed builds can provide default public-client ids for normal users. Advanced users can type their own client id in the connect form. App registrations should allow the loopback redirect URIs http://127.0.0.1:1456/auth/callback for OneDrive and http://127.0.0.1:1457/auth/callback for Dropbox.

Settings

Settings are grouped the same way the app uses them: run defaults first, then connections, extensions, experience, and system controls.

• Settings - Target sets the local target machine and default folder for new runs.
• Settings - Model & Safety stores account-level model routing, reasoning level, and permission defaults.
• Settings - Agent Prompt stores system prompt mode, custom system prompt text, global rules, and extension contribution categories for tools, skills, and MCP servers.
• Settings - MCP manages the MCP defaults used when a launch does not specify its own context servers.
• Settings - LLM Providers manages provider accounts, keys, browser login accounts, and the default provider account used when a launch does not specify one.
• Settings - Storage lists installed storage providers, connects storage accounts, shows extension-catalog provider availability, chooses inline or cloud-link attachment delivery, and configures optional cloud session replication. P2P replication remains enabled separately for paired devices.
• Project profile - Run defaults stores shared project defaults for model, reasoning, permission mode, MCP presets, project rules, and project system prompt. New workspaces under the project inherit these defaults.
• Workspace settings stay thin: they mainly override target machine, folder, labels, memory-pack location, and optional workspace rules.
• Settings - Extension Catalog manages extension install/update/uninstall, target-machine placement, lifecycle operations, logs, catalog sources, and granted capabilities.
• Settings - Extension Settings shows settings panels contributed by installed extensions.
• Settings - Appearance sets the local Glixo Code font preset used by the chat, sidebar, launcher, and settings modals.
• Settings - Notifications controls the in-app drawer/toasts, native delivery mode, critical alert policy, and per-agent or per-extension notification gates.
• Settings - Agxos configures replay seeding, desktop activity sharing, skin/profile/persona, extension update policy, anonymous telemetry, and app-creator behavior.
• Settings - Sync & Reset explains what syncs, what stays local, and resets local run defaults without touching providers, storage, extensions, or notifications.

Effective launch defaults resolve from the launch/session choice first, then project defaults, then account defaults. Workspace settings can still override machine, path, runtime choices, MCP presets, and workspace rules when a specific workspace needs them.

Start an agent session

1. Open or create a workspace.
2. Pick the target machine or browser sandbox.
3. Select a provider account, model, reasoning level, and permission mode.
4. Describe the task in the composer. Be specific about files, tests, constraints, and what done means.

During a session, the main chat shows user and agent messages. The right rail shows supporting views such as files, changes, session stats, and notifications. Use checkpoints before risky edits so you can return to a known-good state.

Permissions and safety

Glixo Code is designed for human-in-the-loop work. The agent can propose commands and edits, but permission settings decide what it may do automatically.

• Ask is best while learning a repo or using a new tool.
• Plan/review modes help with larger changes before edits start.
• More permissive modes are useful only after the workspace and command surface are trusted.

Native approve, deny, stop, or retry actions are intentionally not performed directly from system notifications. Notifications open the correct session UI so existing approval controls handle the decision.

Notifications

The notification drawer lives in the right rail. Use it to review agent contact messages, approval requests, completed runs, failed runs, workflow gates, schedule updates, and system notices.

Clicking a notification opens the relevant session or workflow view. Approval notifications focus the approval controls; completion and failure notifications focus the latest session activity.

Agxos mode

Agxos is the embedded agentic OS inside Glixo. Use it when the task is less about editing an existing repo and more about creating, forking, running, or replaying small apps.

• App Creator turns a prompt into a runnable app.
• Catalog apps can be installed, forked, and changed.
• Replays make sessions shareable as small browser links.

Extensions

Extensions add IDE panels, tools, skills, LLM provider definitions, storage provider definitions, and Agxos apps. Browse installable modules at extend.glixo.io.

Install opens Glixo Code through a deep link. After installation, LLM provider extensions appear in Settings - LLM Providers, storage provider extensions appear in Settings - Storage, and UI/tool extensions appear in their contributed surfaces.

Agent contribution controls live under Settings - Agent Prompt. For each installed extension, you can allow or block whole categories: agent tools, skills, and MCP servers. Per-item toggles are intentionally deferred so v1 uses the same audited capability grants as extension install consent.

Shared agent memory is a core Glixo Code feature, not something installed as an extension. Memory-related extensions can add views or read-only tools, but the storage boundary stays owned by the app runtime.

Troubleshooting