Agent Zero Launcher is an Electron desktop app for installing, running, switching, inspecting, and opening Dockerized Agent Zero instances without making Docker the first thing a user has to understand.
It is intentionally small at the shell boundary: renderer code expresses user intent, the Electron shell owns privileged IPC, and the Docker manager owns image, container, release, storage-volume, and remote-instance orchestration.
Tab switching follows the current order in the main window and excludes detached Instances.
Tabs use the Instance's favicon by default. Colour/Icon offers Favicon alongside the custom icons, including Globe; your saved custom choice takes precedence. Use Upload image to choose your own image or SVG, then Save to keep it as the Instance icon. The Launcher saves a copy, so you can move the source file. The first colour option, Custom, opens a colour picker alongside the presets.
The launcher has two layers:
Shell (shell/)
shell/docker_manager/ and shell/docker_adapter/.Renderer content (app/)
<x-component> includes.content.json by GitHub Actions for release content updates.a0app:// protocol so fetch(), ES module imports, and relative URLs work like they would on a local web server.Packaged and normal non-local runs load content.json from the latest configured GitHub Release and cache it under Electron userData. Local UI work should opt into local content explicitly.
Packaged runs also use electron-updater metadata from the latest launcher GitHub Release. When a newer executable exists, the startup screen can offer an Update button that downloads the updater payload, then restarts to install it once the payload is ready. Continue opens the launcher without updating.
Runtime setup and repair notes are in docs/runtime-troubleshooting.md.
npm install
npm start
Plain npm start exercises the release-content path. That means it may show the latest downloaded content.json, not your edited local app/ files.
For local UI development, run:
A0_LAUNCHER_LOCAL_REPO=. npm start
You can also use the current working directory when it contains app/index.html and package.json:
A0_LAUNCHER_USE_LOCAL_CONTENT=1 npm start
Content-source precedence:
A0_LAUNCHER_LOCAL_REPO=<path>A0_LAUNCHER_USE_LOCAL_CONTENT=1content.jsonTo test release content from a fork or another repository:
A0_LAUNCHER_GITHUB_REPO="owner/a0-launcher" npm start
Useful backend overrides:
A0_BACKEND_GITHUB_REPO="owner/agent-zero" npm start
A0_BACKEND_IMAGE_REPO="namespace/agent-zero" npm start
The default backend image is agent0ai/agent-zero, and the default backend release metadata repository is agent0ai/agent-zero.
Launcher checks the official A0 CLI in the background at startup, installing it when missing or incompatible and updating it when a newer release is available. This does not enable Host access: a gateway runs only for an Instance whose Host access setting was explicitly enabled while its Launcher tab or detached window is open. Each local and saved remote Instance menu shows Install A0 CLI while the system CLI is missing, then replaces it with Open A0 CLI. A0 CLI v2.5 is the first release carrying the Launcher gateway contract. Launcher 1.4 uses the computer_use_setup_v1 capability introduced in A0 CLI 2.6 to stage macOS Accessibility and Screen Recording setup after Computer Use is enabled. Saved permission choices remain on when runtime setup needs attention; subsequent launches preflight silently instead of reopening system prompts.
There is no default npm test contract yet. For quick validation, use:
node --check shell/main.js
node --check shell/preload.js
node --check shell/docker_manager/index.js
node --check app/docker_manager.js
git diff --check
For visible UI changes, run local content and inspect the affected screen:
A0_LAUNCHER_LOCAL_REPO=. npm start
npm install --prefix packaging
npm run desktop:dist
npm run desktop:dist:mac
npm run desktop:dist:win
npm run desktop:dist:linux
Platform-specific examples:
npm run desktop:dist:mac -- --arch arm64
npm run desktop:dist:mac -- --arch x64
npm run desktop:dist:win -- --arch arm64
npm run desktop:dist:win -- --arch x64
npm run desktop:dist:linux -- --arch arm64
npm run desktop:dist:linux -- --arch x64
Release artifacts are:
electron-updater metadata filescontent.jsonLinux DEB/RPM and Windows Squirrel/NuGet artifacts are intentionally not published in the updater-capable release path unless the product decision changes.
Packaged updater debugging follows the Space Agent flow. Open DevTools in a packaged launcher and use:
space.checkForUpdates()
space.debugReinstall('v0.4')
space.installUpdate()
debugReinstall(version) stages and downloads the requested release metadata, including downgrades. After it finishes, click Restart on the startup screen or run space.installUpdate().
For local or fork builds, unsigned macOS artifacts are usually enough:
SKIP_SIGNING=1 npm run desktop:dist:mac
Release-grade macOS signing and notarization in GitHub Actions require:
MACOS_CERT_P12MACOS_CERT_PASSPHRASEAPPLE_IDAPPLE_PASSWORDAPPLE_TEAM_IDWhen Apple credentials are absent, the workflow still builds unsigned macOS artifacts.
GitHub Actions owns the release path:
v* tag intentionally.build.yml builds updater-capable executable artifacts, stages canonical release asset names, creates or updates the GitHub Release, and uploads installers plus updater metadata.bundle-content.yml checks out the tag, bundles app/ into content.json, and uploads it to the release.Two-segment tags such as v1.8 are the public release shape. Executable builds normalize them to full semver versions such as 1.8.0 only where packaging or updater tooling requires it, while public asset names keep 1.8.
After publishing, verify release assets with:
gh release view <tag> --repo agent0ai/a0-launcher --json assets \
--jq '[.assets[].name]'
a0-launcher/
├── .github/workflows/ # Release executable and content bundle workflows
├── app/ # Static renderer source content
│ ├── a0ui/ # Portable Agent Zero UI primitives and vendor assets
│ ├── components/ # Docker Manager component views
│ ├── docker_manager.css # Launcher UI styles
│ ├── docker_manager.js # Renderer state coordinator and action facade
│ └── index.html # Renderer entrypoint
├── docs/ # Supplemental user-facing docs and release notes
├── packaging/ # electron-builder release and updater metadata tooling
├── scripts/ # Build metadata and bootstrap helpers
├── shell/ # Electron shell, preload, content loading, IPC
│ ├── docker_adapter/ # Docker and registry abstraction layer
│ └── docker_manager/ # Agent Zero image, instance, release, and volume logic
├── AGENTS.md # Repo-wide coding-agent contract
├── forge.config.js # Electron Forge makers and packaging config
└── package.json
Coding agents should read AGENTS.md first. Each subtree may also have its own AGENTS.md with closer implementation contracts.
MIT
JavaScript
90.5%
CSS
6.7%
HTML
2.3%
Agent Zero Launcher is an Electron desktop app for installing, running, switching, inspecting, and opening Dockerized Agent Zero instances without making Docker the first thing a user has to understand.
It is intentionally small at the shell boundary: renderer code expresses user intent, the Electron shell owns privileged IPC, and the Docker manager owns image, container, release, storage-volume, and remote-instance orchestration.
Tab switching follows the current order in the main window and excludes detached Instances.
Tabs use the Instance's favicon by default. Colour/Icon offers Favicon alongside the custom icons, including Globe; your saved custom choice takes precedence. Use Upload image to choose your own image or SVG, then Save to keep it as the Instance icon. The Launcher saves a copy, so you can move the source file. The first colour option, Custom, opens a colour picker alongside the presets.
The launcher has two layers:
Shell (shell/)
shell/docker_manager/ and shell/docker_adapter/.Renderer content (app/)
<x-component> includes.content.json by GitHub Actions for release content updates.a0app:// protocol so fetch(), ES module imports, and relative URLs work like they would on a local web server.Packaged and normal non-local runs load content.json from the latest configured GitHub Release and cache it under Electron userData. Local UI work should opt into local content explicitly.
Packaged runs also use electron-updater metadata from the latest launcher GitHub Release. When a newer executable exists, the startup screen can offer an Update button that downloads the updater payload, then restarts to install it once the payload is ready. Continue opens the launcher without updating.
Runtime setup and repair notes are in docs/runtime-troubleshooting.md.
npm install
npm start
Plain npm start exercises the release-content path. That means it may show the latest downloaded content.json, not your edited local app/ files.
For local UI development, run:
A0_LAUNCHER_LOCAL_REPO=. npm start
You can also use the current working directory when it contains app/index.html and package.json:
A0_LAUNCHER_USE_LOCAL_CONTENT=1 npm start
Content-source precedence:
A0_LAUNCHER_LOCAL_REPO=<path>A0_LAUNCHER_USE_LOCAL_CONTENT=1content.jsonTo test release content from a fork or another repository:
A0_LAUNCHER_GITHUB_REPO="owner/a0-launcher" npm start
Useful backend overrides:
A0_BACKEND_GITHUB_REPO="owner/agent-zero" npm start
A0_BACKEND_IMAGE_REPO="namespace/agent-zero" npm start
The default backend image is agent0ai/agent-zero, and the default backend release metadata repository is agent0ai/agent-zero.
Launcher checks the official A0 CLI in the background at startup, installing it when missing or incompatible and updating it when a newer release is available. This does not enable Host access: a gateway runs only for an Instance whose Host access setting was explicitly enabled while its Launcher tab or detached window is open. Each local and saved remote Instance menu shows Install A0 CLI while the system CLI is missing, then replaces it with Open A0 CLI. A0 CLI v2.5 is the first release carrying the Launcher gateway contract. Launcher 1.4 uses the computer_use_setup_v1 capability introduced in A0 CLI 2.6 to stage macOS Accessibility and Screen Recording setup after Computer Use is enabled. Saved permission choices remain on when runtime setup needs attention; subsequent launches preflight silently instead of reopening system prompts.
There is no default npm test contract yet. For quick validation, use:
node --check shell/main.js
node --check shell/preload.js
node --check shell/docker_manager/index.js
node --check app/docker_manager.js
git diff --check
For visible UI changes, run local content and inspect the affected screen:
A0_LAUNCHER_LOCAL_REPO=. npm start
npm install --prefix packaging
npm run desktop:dist
npm run desktop:dist:mac
npm run desktop:dist:win
npm run desktop:dist:linux
Platform-specific examples:
npm run desktop:dist:mac -- --arch arm64
npm run desktop:dist:mac -- --arch x64
npm run desktop:dist:win -- --arch arm64
npm run desktop:dist:win -- --arch x64
npm run desktop:dist:linux -- --arch arm64
npm run desktop:dist:linux -- --arch x64
Release artifacts are:
electron-updater metadata filescontent.jsonLinux DEB/RPM and Windows Squirrel/NuGet artifacts are intentionally not published in the updater-capable release path unless the product decision changes.
Packaged updater debugging follows the Space Agent flow. Open DevTools in a packaged launcher and use:
space.checkForUpdates()
space.debugReinstall('v0.4')
space.installUpdate()
debugReinstall(version) stages and downloads the requested release metadata, including downgrades. After it finishes, click Restart on the startup screen or run space.installUpdate().
For local or fork builds, unsigned macOS artifacts are usually enough:
SKIP_SIGNING=1 npm run desktop:dist:mac
Release-grade macOS signing and notarization in GitHub Actions require:
MACOS_CERT_P12MACOS_CERT_PASSPHRASEAPPLE_IDAPPLE_PASSWORDAPPLE_TEAM_IDWhen Apple credentials are absent, the workflow still builds unsigned macOS artifacts.
GitHub Actions owns the release path:
v* tag intentionally.build.yml builds updater-capable executable artifacts, stages canonical release asset names, creates or updates the GitHub Release, and uploads installers plus updater metadata.bundle-content.yml checks out the tag, bundles app/ into content.json, and uploads it to the release.Two-segment tags such as v1.8 are the public release shape. Executable builds normalize them to full semver versions such as 1.8.0 only where packaging or updater tooling requires it, while public asset names keep 1.8.
After publishing, verify release assets with:
gh release view <tag> --repo agent0ai/a0-launcher --json assets \
--jq '[.assets[].name]'
a0-launcher/
├── .github/workflows/ # Release executable and content bundle workflows
├── app/ # Static renderer source content
│ ├── a0ui/ # Portable Agent Zero UI primitives and vendor assets
│ ├── components/ # Docker Manager component views
│ ├── docker_manager.css # Launcher UI styles
│ ├── docker_manager.js # Renderer state coordinator and action facade
│ └── index.html # Renderer entrypoint
├── docs/ # Supplemental user-facing docs and release notes
├── packaging/ # electron-builder release and updater metadata tooling
├── scripts/ # Build metadata and bootstrap helpers
├── shell/ # Electron shell, preload, content loading, IPC
│ ├── docker_adapter/ # Docker and registry abstraction layer
│ └── docker_manager/ # Agent Zero image, instance, release, and volume logic
├── AGENTS.md # Repo-wide coding-agent contract
├── forge.config.js # Electron Forge makers and packaging config
└── package.json
Coding agents should read AGENTS.md first. Each subtree may also have its own AGENTS.md with closer implementation contracts.
MIT
JavaScript
90.5%
CSS
6.7%
HTML
2.3%