# OpenPets: a desktop pet platform that coding agents can drive

> OpenPets puts an animated companion on your desktop and exposes a sandboxed plugin SDK so Claude Code, OpenCode, Cursor, Pi and MCP clients can trigger pet reactions. Here is what the repository documents, and where it stays silent.

**OpenPetsHQ/openpets** — Local first, desktop companion platform with animated pets, plugin SDK and coding-agent integrations.

- Repository: https://github.com/OpenPetsHQ/openpets
- Website: https://openpets.dev
- Stars: 1,255 · Forks: 118
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/openpetshq-openpets

## What OpenPets actually solves, and who it is for

The README frames the project as "a desktop companion platform with pets, plugins, and optional local agent integrations." Stripped of the framing, the product is two things stacked on one Electron shell. The first is an animated pet that idles, wanders and reacts, shipped with a set of official plugins: focus timers, reminders, mood check-ins, mini games, launch shortcuts, hydration nudges and a Tamagotchi-style virtual pet with hunger, affection and energy. The second is a plugin host with a declared permission model, which is the part that matters to engineers.

The audience splits cleanly. Casual users get a working app with no agent setup: the README states a pet appears immediately after launch. Developers get a sandboxed JavaScript and TypeScript runtime, SDK v3, for writing new pet abilities. The overlap is the interesting case: someone running several Claude Code, OpenCode, Cursor or Pi sessions who wants a single ambient signal on the desktop instead of another terminal to watch.

That second use is narrow by design. The README is explicit that agent integrations drive local pet reactions "without exposing prompts, code, paths, logs, or secrets in speech bubbles." So the pet cannot tell you what a session is doing. It can only tell you that something happened, in a form you defined.

## How the sandbox and the ctx object divide work

Each JavaScript plugin runs inside a sandboxed BrowserWindow host environment rather than in the main process. Plugins do not draw their own UI. They describe actions, HUDs and notifications, and the desktop host renders them. The README states that plugin HTML or JS cannot render raw HTML or execute arbitrary scripting inside a pet window. That is the central architectural decision, and it costs plugin authors flexibility: anything the host does not know how to render is not available.

Plugins reach the desktop through a single ctx object. ctx.pets and ctx.pet handle spawning, moving, animating and reacting. ctx.ui covers alerts, transient and pinned bubbles, custom menus, panels and status HUDs, with pinned mini HUD bubbles supporting compact 2x2 grid layouts with progress bars. ctx.schedule takes timer hooks in the forms once, every, daily, cron and at. ctx.storage is a JSON key-value store with change subscriptions. ctx.ai and ctx.secrets hook into a host-configured provider (Anthropic, OpenAI or Ollama) without exposing API keys to plugin source. The remaining surface includes events, assets, bus, net with streaming, notify, voice for TTS and push-to-talk STT, auth via a PKCE browser flow, files through secure picked OS dialogs, system, commands, status and log.

Two guards stand out. Network fetch requests are limited to developer-declared hostnames, and the README says they are guarded against local SSRF. Permissions must be declared in the manifest and approved by the user at install, with flagged sensitive APIs such as voice:listen, clipboard and pet:speak:dynamic requiring explicit consent toggles. The manifest is therefore the real security boundary, and it is only as good as the user reading it.

## Installing OpenPets and enabling a first plugin

The README points users at the releases page rather than a package manager. Download the artifact matching your platform: OpenPets-*-mac-arm64.dmg for Apple Silicon, OpenPets-*-mac-x64.dmg for Intel Macs, OpenPets-*-win-x64-setup.exe for Windows, or OpenPets-*-linux-x86_64.AppImage for Linux. Launch it and a pet appears. No agent connection is required for this step.

The README notes that Windows installers are signed, while macOS builds may still be unsigned and can trigger a security warning. If macOS blocks the app, the documented remedy is to clear the quarantine flag:

```bash
xattr -dr com.apple.quarantine /Applications/OpenPets.app
```

After that, open the Control Center and the Official Plugin Catalog. Enable Focus Buddy for a Pomodoro-style timer or Reminders for snoozeable bell alerts with custom audio tones. The Pet Gallery lists installed pets, previews their animation frames, and lets you assign which pet monitors which workspace or agent window. That assignment is the whole configuration for the agent use case: pick a pet, point it at a window.

Plugin authors go through the CLI instead. The README gives this scaffold command, with templates named blank, reminder, ambient, ai-chat, tamagotchi and calendar:

```bash
npx @open-pets/cli plugin new "My Plugin" --templ
```

The README excerpt cuts off mid-flag, so treat the template argument as something to confirm against the CLI's own help output before you rely on it.

## Where OpenPets is the wrong tool

The permission model is a real constraint, not a formality. A plugin that needs clipboard access or dynamic speech must be approved through an explicit consent toggle at install time. If your intended behaviour depends on reading the clipboard silently, or on the pet speaking arbitrary text generated at runtime, you are working against the design rather than with it. The same applies to networking: fetch is limited to hostnames the developer declared in advance, so a plugin that discovers endpoints at runtime will not work.

Host-rendered UI is the second limit. Because the host renders panels, bubbles and HUDs, a plugin cannot reproduce a custom interface it designed in HTML. The README describes compact 2x2 grid layouts with progress bars as the supported shape for pinned HUDs. Anything richer has no documented path.

The agent integration is the third. It is one-directional and deliberately opaque. If you want a dashboard showing which agent session is blocked on which tool call, the pet is not that. The README positions the integration as reactions driven without exposing prompts, code, paths, logs or secrets. That is a privacy property, and it is also a ceiling on usefulness.

Finally, there is no documented rollback. The README does not describe how to revert a plugin to a previous version, nor what happens to ctx.storage data when a plugin is removed. If you are deploying a plugin across a team, that gap is worth resolving before you depend on it.

## How it differs from a plain Electron pet or a headless agent UI

Two adjacent categories exist. The first is the classic desktop pet: a sprite that walks around the screen and does nothing else. OpenPets is a superset of that, and the difference is entirely the plugin host. A plain pet has no permission manifest, no scheduled hooks, no storage, and no way for an external process to trigger a reaction. OpenPets exposes all four through ctx, which is why the same binary can be a Pomodoro timer, a hydration nudge, or an agent sidekick depending on what is installed.

The second category is the headless agent monitor: a terminal or web UI that lists running sessions and their state. That approach gives you detail OpenPets deliberately withholds, since it can read prompts and logs. It also requires you to keep looking at it. OpenPets trades that detail for ambient presence. The pet sits in peripheral vision and reacts; you notice it without switching windows.

A related phrase that appears in search data is "AI desktop pet github." The distinction worth drawing is that OpenPets is not only an AI pet. The AI layer is optional and off by default in the sense that the desktop app works without any agent connected. The plugin SDK, not the model integration, is the load-bearing part of the project.

## Maintenance, licensing and what upgrading costs

OpenPets is MIT licensed. The workspace package.json carries the same MIT identifier, and the repository is a pnpm workspace with packageManager set to pnpm@11.0.8 and engines.node at >=20. For anyone building plugins, that means Node 20 or newer and pnpm if you work inside the monorepo. The SDK itself is consumed as @open-pets/plugin-sdk, and the CLI as @open-pets/cli.

The repository is not archived, and the last push was on 2026-09-05. Releases have arrived roughly monthly: v3.3.0 on 2026-07-11, v3.4.0 on 2026-08-09, and v3.5.0 on 2026-09-02. The SDK is labelled v3, and the workspace version tracks the same 3.5.0 number, so plugin authors should expect the SDK to move with desktop releases rather than on a separate cadence.

That coupling is the upgrade cost. There is no documented compatibility policy in the README, and no migration notes for plugin authors between v3.x releases. The monorepo does ship plugins:validate-release and plugins:validate-live scripts, which suggests validation runs against published plugins, but the README does not explain what those scripts check or whether they gate a release. If you maintain a plugin, budget for reading release notes before each desktop update rather than assuming the ctx surface is frozen.

Licence implications are worth stating plainly without legal advice: MIT permits commercial use and modification, and requires the licence and copyright notice to be preserved. The repository ships a LICENSE file at the top level.

## Conclusion

OpenPets fits people who want a desktop companion and are willing to install a sandboxed plugin runtime, and TypeScript developers who want a small, permissioned host to build pet behaviour against. It is a poor fit if you want a headless agent dashboard, or if you expect the pet to reason about your code: the README states agent integrations drive reactions without exposing prompts, code, paths, logs or secrets in speech bubbles, so the pet is an indicator, not an analyst. Before adopting, verify two things yourself: whether your platform has a signed build, since the README notes macOS builds may still be unsigned, and whether the plugin you need declares the permissions you are willing to grant at install.

## FAQ

### Where can I download OpenPets for free?

The README points to the GitHub releases page, where builds are published per platform: OpenPets-*-mac-arm64.dmg, OpenPets-*-mac-x64.dmg, OpenPets-*-win-x64-setup.exe and OpenPets-*-linux-x86_64.AppImage. The project is MIT licensed and the desktop app works without connecting any AI agent.

### What do desktop pets in OpenPets do?

The README describes animated companions that idle, wander and react on the desktop. Official plugins add focus timers, reminders, mood check-ins, mini games, launch shortcuts, hydration nudges and a Tamagotchi-style virtual pet with hunger, affection and energy levels.

### Is OpenPets safe to install?

Plugins run in a sandboxed BrowserWindow host, must declare permissions in a manifest, and require user approval at install, with sensitive APIs such as clipboard and voice:listen behind explicit consent toggles. Network fetches are limited to developer-declared hostnames with SSRF guards. Windows installers are signed; the README notes macOS builds may still be unsigned and can be cleared with xattr -dr com.apple.quarantine.

## Sources

- [License: MIT](https://github.com/OpenPetsHQ/openpets/blob/main/LICENSE)
- [OpenPetsHQ/openpets on GitHub](https://github.com/OpenPetsHQ/openpets)
- [Project website](https://openpets.dev)
- [README](https://github.com/OpenPetsHQ/openpets/blob/main/README.md)
- [Releases](https://github.com/OpenPetsHQ/openpets/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openpetshq-openpets