Halo (openkursar/hello-halo): a local Electron AI workstation with scheduled Digital Humans

The gap Halo targets: an agent with hands, not just a chat window

Most desktop AI assistants answer questions. Halo's stated premise is that the assistant should also click, type, read files and run on a timer. The README frames this as an AI workstation: coding, product design, operations, writing and research in one local application, with no backend service to stand up. The audience is explicit in the tagline, teams and individuals, and the automation examples skew toward Chinese social platforms (Xiaohongshu, Bilibili, Zhihu) and enterprise systems (OA, CRM, ERP, Jira, GitLab, CI/CD).

The distinguishing claim is that the same agent capabilities are shared between conversation mode and the scheduled agents the project calls AI Digital Humans. The README states a Digital Human gets the AI Browser, the AI Terminal, WeCom/WeChat messaging, and the ability to change Halo's own settings. That is a broader surface than a chat assistant, and it is also the reason the security questions in this article are not hypothetical.

Pluggable engines, a browser the AI drives, and Browser Actions as the execution layer

The architecture visible in the repository is an Electron application (electron.vite.config.ts, electron-builder.cjs, main entry ./out/main/index.mjs) with a TypeScript source tree under src/, an android/ and ios/ directory for the remote clients, and a Capacitor config for the mobile side. The AI engine is not baked in: the README describes a pluggable engine architecture supporting Claude Code and Codex, and the .env.example lists Anthropic, OpenAI, DeepSeek, Moonshot (Kimi) and generic OpenAI-compatible endpoints for its test configuration, which suggests the provider layer is meant to be swappable.

The mechanism worth understanding is the Browser Action. The README calls it a special kind of Skill: a reusable .js script that performs one concrete operation on one platform, run inside a real browser with access to the page DOM, cookies and internal APIs. The division of labour is stated plainly: the AI decides what to do and when, the script knows how. This is a deliberate rejection of the click-around-and-hope approach, and it is the most defensible design decision in the project. It also means the quality of any given automation depends on whoever wrote that script, not on the model.

Digital Humans are the scheduling layer on top. Give one a task and an execution frequency and it runs without supervision, with the README claiming long-term memory so each run continues from the last rather than starting cold. The README does not describe how that memory is stored, how large it grows, or how you clear it.

Installing Halo and getting a first agent running

The README points to a Download section and the project homepage at hello-halo.cc for the packaged application. The build scripts in package.json show the release path: electron-builder with per-platform targets for mac, win and linux, plus a signed macOS variant. If you are installing rather than building, use the releases page rather than the source tree.

For a source checkout, the development command sets a separate data directory so your work does not collide with an installed copy:

git clone https://github.com/openkursar/hello-halo
cd hello-halo
npm install
npm run dev

The dev script bundles built-in apps, regenerates the API reference, and launches electron-vite with HALO_DATA_DIR pointed at ~/.halo-dev. The postinstall hook runs scripts/postinstall.mjs, so expect the install step to do more than fetch packages.

Provider credentials for the test and translation tooling come from a local env file. Copy the example and edit it:

cp .env.example .env.local

HALO_TEST_API_KEY=your_test_api_key
HALO_TEST_API_URL=https://api.anthropic.com
HALO_TEST_MODEL=claude-sonnet-5
HALO_TEST_PROVIDER=anthropic

The .env.example notes that .env.local is gitignored. The provider ID must match a built-in provider id, and the file lists Anthropic, OpenAI, DeepSeek and Moonshot as supported shapes. GH_TOKEN in the same file is only for publishing to GitHub Releases, not for running the app.

For a first real use, the README's own walkthrough is the OA Approval Assistant: a Digital Human that patrols a login-required internal system on a schedule, documented at hello-halo.cc/docs/digital-humans/guide-02-build.html. That is the honest starting point, because it exercises the browser, the schedule and the memory in one task. A simpler first step is to install a ready-made Browser Action from the AI Digital Human Store for a platform you already use, then attach it to a Digital Human with a daily frequency.

Where Halo gets uncomfortable: cookies, private systems and an unclear licence

The README's own selling point is the limitation. Browser Actions run with full access to page DOM, cookies and internal APIs. That is what makes them reliable against a login-required OA or CRM system, and it is also what makes the desktop machine a credential store for every system you automate. The README does not document a sandbox, a permission prompt per Action, or a way to scope an Action to a subset of a session. If your compliance model requires that no automated process holds a live session cookie for an internal system, Halo is the wrong tool, regardless of how well it works.

The licence situation needs a look before adoption. package.json declares "license": "MIT", the README badge links to an MIT badge, and the top-level LICENSE file exists. But the repository metadata reports the licence as NOASSERTION, which is what a host says when it cannot match the file to a known licence. One of those two signals is wrong, and the README does not explain which. A team that needs a clean licence determination should read LICENSE directly rather than trusting the badge.

Two more gaps are visible in what the README does not say. There is no documented rollback for a failed Digital Human run, and no statement about what happens when a Browser Action breaks because a platform changed its DOM. The README positions Actions as stable and auditable, but a .js script pinned to a page structure is exactly the kind of artifact that rots quietly.

Halo versus a plain Claude Code or Codex install

The obvious alternative is the engine underneath: run Claude Code or Codex directly in a terminal and write your own cron entries. The difference in approach is real. A terminal agent has your filesystem and your shell, and nothing else. It cannot log into Xiaohongshu, it has no persistent scheduled identity, and it has no GUI for a manager to check progress from a phone.

Halo adds three things on top of that engine: a browser it controls through reusable scripts, a scheduler with per-agent memory, and remote access from phone, H5, WeChat or an Android client. The README also claims 100% compatibility with Claude Code's agent capabilities, MCP and Skills, which means you are not giving up the engine's own ecosystem by wrapping it.

The trade is weight and trust. A terminal agent is a process you start and stop. Halo is a desktop application with an embedded browser, a terminal, a knowledge base and a mobile companion, and it is designed to keep running. The README states the product layer is over 300,000 lines of code. That is a large surface to audit before you let it hold sessions for internal systems, and the repository's tests/ directory is the only auditing aid the layout hints at.

Maintenance, upgrade cost and what the release cadence implies

The last push to the repository was on 2026-09-10, the same day as the v2.1.15 release, so the project is under current development. The release history shows v2.1.12 on 2026-07-05, v2.1.13 on 2026-07-30 and v2.1.15 on 2026-09-10, roughly monthly, while package.json carries version 2.1.16-dev.0. That is a steady cadence with patch-level releases, not a rewrite cycle.

The upgrade cost sits in the Browser Actions, not the application. Upgrading Halo is a download. Upgrading the automations you depend on means checking whether the platform's page structure still matches the .js script, and the README offers no compatibility contract for that. Private Actions written for internal systems are yours to maintain. There is also no documented rollback path for a Digital Human that misbehaves mid-run, so the practical mitigation is frequency and scope, not recovery.

On licensing, the MIT declaration in package.json and the MIT badge are permissive signals, but the NOASSERTION metadata means the terms have not been mechanically confirmed. That is a fact to resolve with whoever reads LICENSE, not a legal conclusion.

Editorial conclusion

Adopt Halo if you want an agent that already has a browser, a shell and a schedule attached, and you are willing to run it from a desktop install rather than a container. Do not adopt it if your policy forbids an agent holding session cookies for internal systems, or if you need a licence file that states its own terms before procurement will sign. Verify two things first: that LICENSE actually contains MIT text, since the host reports NOASSERTION while package.json declares MIT, and that the engine you intend to use (Claude Code, Codex, or another provider configured through the HALO_TEST_* variables) is one you are allowed to point at your data.

Frequently asked questions

Official sources

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