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

The problem is ambient feedback, not productivity metrics

Most developer tooling reports through text: a terminal line, a notification, a dashboard tab you forget to open. OpenPets takes the opposite route. According to the README, it puts an animated companion on the desktop, then lets plugins turn it into a focus buddy, reminder system, tiny game, launcher, or coding-agent sidekick. The audience splits cleanly in two. The first group is people who want a desktop companion and nothing more; the README states the desktop app is fully functional out of the box with the official plugin lineup, and that no agent setup is required. The second group is developers who want a visual surface their coding agents can drive, which is where Claude Code, OpenCode, Cursor, Pi and MCP clients enter. It is worth being precise about what the agent layer does not do. The README says these clients can drive local pet reactions without exposing prompts, code, paths, logs, or secrets in speech bubbles. That is a narrow claim about what appears on screen, not a claim about sandboxing your agent or auditing its behaviour.

Sandboxed BrowserWindow hosts and a host-rendered UI

The architectural decision that shapes everything else is where plugin code runs. Each JavaScript plugin runs inside a sandboxed BrowserWindow host environment, and plugins do not draw their own interface. They describe actions, HUDs and notifications, and the desktop host renders them. The README is explicit that HTML or JS code cannot render raw HTML or execute arbitrary scripting inside a pet window. That constraint cuts both ways. You get a predictable rendering surface and no plugin can inject markup into the pet window, but you also lose layout control. The compensation is a set of host-provided primitives: pinned mini HUD bubbles support compact 2x2 grid layouts with progress bars, which is the mechanism the Virtual Pet plugin uses to display hunger, affection and energy as a live status pin. If your idea needs a custom chart or a free-form canvas, this model will fight you. If your idea is a status readout, a timer, or a menu, the primitives cover it.

The ctx object: what a plugin can actually touch

Everything a plugin does flows through a single ctx object. ctx.pets and ctx.pet handle spawning, moving, animating and reacting, so a plugin can manage both the default pet and additional spawned instances. ctx.ui covers alerts, transient and pinned bubbles, custom menus, panels and status HUDs. ctx.schedule provides timer hooks in five shapes: once, every, daily, cron and at. ctx.storage is a JSON key-value store with change subscriptions, which is the simplest way to persist state across restarts. The two entries that deserve the most attention are ctx.ai and ctx.secrets. The README states that plugins can hook into the user's host-configured AI provider (Anthropic, OpenAI, Ollama) without exposing API keys to the plugin source. That is a meaningful separation: the key lives with the host, and the plugin calls through. The remaining surface is broad: events, assets, bus, net with streaming support, notify, voice for TTS and push-to-talk STT, auth via a PKCE browser flow, files through secure picked OS dialogs, plus system, commands, status and log. The breadth is the risk. A large ctx surface means a large permission surface, and the README's own list of flagged sensitive APIs (voice:listen, clipboard, pet:speak:dynamic) suggests the maintainers know which ones need friction.

Permissions, SSRF guards and the install-time consent model

Permissions must be declared in the plugin manifest and approved by the user at install time, and flagged sensitive APIs require explicit consent toggles. Network access is not open by default: fetch requests are limited to developer-declared hostnames and guarded against local SSRF. This is a reasonable design for a platform whose plugins are third-party code running next to your desktop. The limitation is the approval model itself. Consent at install is a single moment, and the README does not describe any runtime re-prompting when a plugin starts using an API it declared but has not used before. A plugin that declares clipboard access and uses it six months later still has the grant. Whether that matters depends on how you source plugins; the official catalog shipped with v3 is a different trust proposition from something you pull off a repository. There is also no statement in the supplied material about a plugin signing or verification step, so the practical trust boundary is the manifest plus your own reading of the source.

Getting it running: installers, the quarantine flag and the CLI

Installation is a download, not a build. The README lists four artifacts: OpenPets-*-mac-arm64.dmg for Apple Silicon, OpenPets-*-mac-x64.dmg for Intel Macs, OpenPets-*-win-x64-setup.exe for Windows, and OpenPets-*-linux-x86_64.AppImage for Linux. Windows installers are signed. macOS builds may still be unsigned and can trigger a security warning; the documented workaround is a terminal command:

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

That is a real operational cost. Anyone distributing the app inside a managed fleet will hit Gatekeeper before they hit a single feature. For plugin work, the entry point is the official CLI. The README gives this example for scaffolding:

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

The command is truncated in the supplied material at --templ, so the exact flag name is not confirmed here. The template list is confirmed: blank, reminder, ambient, ai-chat, tamagotchi and calendar. The SDK package is @open-pets/plugin-sdk. Beyond scaffolding, the README refers to validating and testing plugins with the CLI but does not show those subcommands, so treat that part as documented-but-unverified.

The official plugin lineup shows what the platform is optimised for

The shipped catalog is the best evidence of intended use. Day Routine tracks habits and reminds you to stretch or step away. Focus Buddy runs Pomodoro-style focus timers. Reminders renders snoozeable bell-alert notifications with custom audio tones. Water Reminder issues regular drinking prompts. Virtual Pet tracks hunger, affection and energy through the pinned HUD. The rest are lighter: Fortune Cookie, Magic 8 Ball, Mood Check-in, Launch Buddy for registering shortcut commands that open local folders, projects or applications. Read as a group, these are all periodic, low-information, single-pet interactions. None of them needs a dense interface. That tells you the plugin SDK is tuned for cadence and small state, not for data-heavy tools. If you are evaluating OpenPets as a general desktop widget runtime, the official lineup is a weak signal for that use case, because none of the shipped plugins pushes the HUD primitives hard.

Where it is the wrong tool, and what to use instead

OpenPets is the wrong choice when the feedback needs to be reliable rather than ambient. A pet that wanders and reacts is a visual presence on a desktop session; it is not an alerting channel, and nothing in the supplied material describes delivery guarantees, escalation, or an audit trail for notifications. If you need a coding agent to tell you that a long-running task failed while you are away from the machine, a desktop pet is a poor transport. The closer alternative is a notification daemon wired directly into your agent's hooks: on Linux, something like notify-send invoked from a shell hook, or a small script that posts to a chat webhook. The difference in approach is that OpenPets owns the rendering and the plugin sandbox, so you get a consistent visual surface across macOS, Windows and Linux at the cost of writing against ctx and its permission model. A daemon gives you full control over the payload and no sandbox, at the cost of platform-specific plumbing and no shared visual identity. Neither is a superset of the other. If you already have a notification pipeline you trust, adding OpenPets on top duplicates it; if you want one pet to reflect several agents at once, which the README's multi-session screenshot suggests is a supported scenario, the notification daemon will not get you there without building the same abstraction yourself.

Maintenance cost and the MIT licence

The release cadence visible in the supplied material is roughly monthly: v3.3.0 in July 2026, v3.4.0 in August, v3.5.0 in September. The repository is not archived, and the last push is dated after the most recent release. For a plugin author, that cadence is the main ongoing cost. The SDK is at v3, and the README presents the plugin platform as having evolved to that point, which implies earlier plugin code may not carry forward without changes. There is no published deprecation policy in the material, so the safe assumption is that ctx surfaces can shift between minor versions and you should pin the SDK version you build against. On licensing, the project is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the extent of what can be said here; the interaction between MIT and any plugins you ship under a different licence is a question for your own counsel, not for this article.

Editorial conclusion

Adopt OpenPets if you want ambient desktop feedback and are willing to write plugins against the ctx surface, and treat the agent layer as a convenience rather than a monitoring tool. Skip it if you need a headless, scriptable notification system or if unsigned macOS builds are a blocker in your environment. Before committing, verify two things: that the permission toggles for voice:listen, clipboard and pet:speak:dynamic behave the way you expect on your platform, and that the network allowlist in your plugin manifest actually blocks the hosts you intend to block.

Official sources

1. License: MIT
2. OpenPetsHQ/openpets on GitHub
3. Project website
4. README
5. Releases