Halo: a desktop AI agent that runs Browser Actions on a schedule

The gap Halo is aimed at: agents that only work while you watch

Most desktop AI assistants are conversational. You open a window, type, read the reply, and close it. The work stops the moment you stop typing. Halo's README frames the product as an AI workstation where Digital Humans run autonomously on a schedule, handling monitoring, reports and routine operations without a screen being watched. The stated targets are concrete: auto-reply to comments on Xiaohongshu, Bilibili and Zhihu, publish scheduled content to Twitter and WeChat Official Accounts, patrol internal OA, CRM and ERP systems for overdue tickets, generate standup reports from Jira, GitLab or GitHub activity, and watch CI/CD pipelines for build failures. The audience is two groups. Individuals who want a local assistant that keeps running after they close the laptop lid, and teams that need automation against internal systems which have no public API. The README claims the product layer is over 300,000 lines of code and that it runs in enterprise environments. Treat those as vendor statements, not measurements. The design bet that matters is the deployment model: the app runs on your machine, the README says data never leaves it, and there is no backend to stand up.

Engine, product layer and the AI-decides-scripts-execute split

Halo separates the agent engine from the product. The engine is pluggable, and the README names Claude Code and Codex as supported backends, with a claim of 100% compatibility with Claude Code's agent capabilities, MCP and Skills. That means the reasoning loop is not Halo's own; Halo supplies the surface around it. Above the engine sits what the README calls the product layer: an embedded AI Browser, an AI Terminal the agent can drive directly, a knowledge base that files are dropped into, remote access clients, and a store of Digital Humans. The mechanism worth understanding is the Browser Action. The README is explicit that this is not a generic browser agent clicking around. A Browser Action is a Skill in the form of a reusable .js script that performs one concrete operation on one platform, running inside a real browser with access to the page DOM, cookies and internal APIs. The model decides what to do and when. The script already knows how. The README argues this is what separates Halo from agents that fumble through a page, and the argument is sound: a deterministic script against a known DOM is reproducible in a way that vision-driven clicking is not. The cost is that someone has to write the script, and it breaks when the target page changes. Halo also claims the agent can operate Halo itself, loading features on demand so idle context is not consumed. That claim is not explained in the material available, so treat it as unverified.

Digital Humans, memory and the scheduler

A Digital Human is created with a task and an execution frequency, then runs on that schedule. The README says Digital Humans share the same capabilities as conversation mode, so a scheduled run can use the browser, the terminal, messaging and Halo's own settings, not just one tool. It also says each run is not a cold start: the Digital Human remembers where it left off, what it saw and what it concluded, and that this compounds over time. How that memory is stored, scoped or expired is not described in the README. Nor does the README describe what happens when a scheduled run fails, whether it retries, how failures are surfaced, or how a partially completed Browser Action is rolled back. For anything touching a production system, those are the questions that decide whether the tool is usable, and the documentation as supplied does not answer them. The store is the distribution mechanism: ready-made Digital Humans install with one click, organisations can deploy a private store, and users can create their own by describing the task in natural language. Ready-made Browser Actions are listed for Xiaohongshu, Bilibili, Zhihu, Twitter/X and WeChat, which suggests the coverage is strongest for Chinese consumer platforms and social publishing, and thinner for arbitrary enterprise software until someone writes the Action.

Getting it running and the config surface

The README's installation path is a download from the releases page, with platform badges for macOS, Windows, Linux and Web. The stated pitch is zero configuration, no backend, IT deploys in minutes. The repository is TypeScript with main as the default branch, and the latest release in the supplied list is v2.1.15, pushed the same day the repository last received a push. The README does not include a package manager install command, a config file schema, or environment variable names. What it does name as user-facing surfaces are the AI Digital Human Store, the Browser Action format (a .js script), the documentation site at hello-halo.cc, and a guide titled Build a Browser Action Digital Human that walks through an OA Approval Assistant patrolling a login-required internal system on a schedule. Remote access is enabled as a feature, after which phone, H5, WeChat and Android clients control the desktop instance. Beyond that, the material does not give concrete keys to set. If you need to know exactly which file holds the engine selection between Claude Code and Codex, or how credentials for a logged-in internal system are stored for a Browser Action, the README does not say, and you should read the linked docs before committing.

Where Halo is the wrong tool

The licence is the first problem. The repository metadata reports NOASSERTION, while the README badge links to an MIT licence. Those two signals disagree, and the discrepancy is not resolved in the material. Until you open the LICENSE file and confirm what it contains, you cannot assume MIT terms apply to the code you would be embedding in an enterprise deployment. That is a practical blocker, not a formality, for anyone planning to fork or redistribute. The second limit is the Browser Action model itself. It trades adaptability for determinism, and the trade runs both ways. A script that hooks into a page's DOM or internal APIs is fragile against a redesign, and the README offers no versioning or health-check story for Actions that silently stop matching. Third, the strongest automation examples are consumer platforms in the Chinese ecosystem and internal enterprise systems. If your targets are Western SaaS products with well-documented public APIs, a plain API integration or an existing workflow tool will be less work than writing and maintaining a browser script. Fourth, the README's claims about enterprise validation and user numbers are unverifiable from the repository, and the 300,000-line figure is a size claim, not a quality one. Finally, the material never explains the security boundary: a scheduled agent with terminal access, browser cookies and messaging control is a wide surface, and the README does not describe sandboxing or permission scoping.

How this differs from n8n and from a raw Claude Code setup

The obvious comparison is a workflow automation tool such as n8n. n8n gives you a visual graph of nodes, each with typed inputs and outputs, and integrations that call documented APIs. It is deterministic by construction and debuggable step by step. Halo inverts the control flow: the agent decides which action to take, and the action is a script rather than a node. That is more flexible when the target has no API and the page changes in ways a fixed graph cannot anticipate, and less predictable when you need to know in advance exactly what a scheduled job will do. The second comparison is running Claude Code directly. Claude Code gives you the agent loop in a terminal with MCP and Skills, but no scheduler, no embedded browser with cookie access, no store, and no WeChat or WeCom control channel. If your automation is already API-shaped and you are comfortable in a terminal, the raw engine plus cron is fewer moving parts. Halo's value is the packaging around the engine, and that value only materialises if you actually use the scheduler, the browser and the remote control.

Maintenance, releases and what the licence question costs you

The release cadence visible in the supplied list is roughly monthly to six-weekly across v2.1.12, v2.1.13 and v2.1.15, with the newest release dated the same day as the last push to main. That is an actively maintained project by the evidence available, though the material gives no support policy, no LTS branch and no deprecation notice for older versions. Upgrading a desktop app is usually a download, but the real upgrade cost sits in the Browser Actions: when a target platform changes its page, every scheduled Digital Human depending on that Action needs the script updated, and the README does not describe a mechanism for detecting or distributing those fixes. If you rely on store Actions for Xiaohongshu or Bilibili, you are depending on someone else's maintenance of scripts against pages you do not control. On licensing, the README badge says MIT and the repository metadata says NOASSERTION. Do not treat either as settled. Confirm the actual LICENSE contents and, if you plan to redistribute or embed Halo, get your own read on it rather than relying on the badge.

Editorial conclusion

Adopt Halo if you want a locally deployed agent that can be scheduled, driven from WeChat or WeCom, and pointed at web systems through reusable JavaScript Browser Actions rather than free-form clicking. Do not adopt it if you need a permissively licensed codebase you can fork freely, or if your automation targets have no stable DOM or internal API for a script to hook into. Before installing, open the LICENSE file and confirm what NOASSERTION actually resolves to, and check the docs for how the Digital Human scheduler handles a failed run, because the README describes memory and judgement but not retry behaviour.

Official sources

1. Issues
2. openkursar/hello-halo on GitHub
3. Project website
4. README
5. Releases