# vscode-pets: ten commands, a sidebar panel, and an activation event you cannot avoid

> The VS Code Pets extension draws a pixel pet in your editor, but its package manifest is the more interesting document: it registers ten commands, can host its panel in the Explorer sidebar or a webview, ships fifteen translation bundles, and asks VS Code to activate it once startup finishes.

**tonybaloney/vscode-pets** — Adds playful pets 🦀🐱🐶 in your VS Code window

- Repository: https://github.com/tonybaloney/vscode-pets
- Website: https://tonybaloney.github.io/vscode-pets
- Stars: 4,174 · Forks: 561
- Language: TypeScript
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/tonybaloney-vscode-pets

## onStartupFinished means the extension loads before you want a pet

The manifest lists fourteen activation events, and the last one is onStartupFinished. That single entry means the extension host loads this extension after startup whether or not you have ever opened a pet, run a pet command or looked at the panel.

Everything else in the list is reactive: ten onCommand entries for the features themselves, a webview panel event for the coding session, and two view events for the Explorer sidebar and the pets view. The startup entry is the odd one out.

That choice buys something real. A pet that only appears after you invoke a command needs a command palette entry to be discoverable, whereas an extension already running at startup can put its panel where you expect it and start drawing when you ask. The cost is that the extension is resident on every window you open, including the ones where you never want a cat. If your VS Code setup is tuned for a small resident set, that is the line to read in the manifest.

## Ten commands, and two different ways to throw something

The command surface is registered up front, which makes each of these runnable from the palette before you have opened the panel.

```json
"onCommand:vscode-pets.start",
"onCommand:vscode-pets.throw-with-mouse",
"onCommand:vscode-pets.throw-ball",
"onCommand:vscode-pets.spawn-pet",
"onCommand:vscode-pets.delete-pet",
"onCommand:vscode-pets.remove-all-pets",
"onCommand:vscode-pets.roll-call",
"onCommand:vscode-pets.export-pet-list",
"onCommand:vscode-pets.import-pet-list",
"onCommand:vscode-pets.change-theme"
```

Two entries do the same thing by different means: throw-ball and throw-with-mouse. The first asks for the item to be launched, the second ties it to your pointer, so you drag the ball rather than click it. That pair is the only place in the manifest where the same feature is deliberately exposed twice.

The rest divide cleanly into lifecycle and housekeeping: start opens a coding session, spawn-pet adds one more pet to it, delete-pet removes a single one, remove-all-pets clears the lot, and roll-call is a group check rather than a state change.

## export-pet-list and import-pet-list move your pets between machines

Two of the ten commands treat the pet list as data: one exports it, one imports it. Nothing else in the manifest suggests persistence or sharing, so these two are the entire portability story.

The reason they exist is visible in the next fact. There is a roll-call command, which sounds like it should be a no-op beyond making pets answer, and then there is the import command that replaces whatever you had. A pet list that can only be rebuilt by hand each time makes the roll call worthless across machines, and makes the choice of species a decision you repeat. The export path lets you keep the set you configured and load it somewhere else.

The documentation site, not the README, is where you find what the exported file looks like and where it is written. The README's own list of things you can do is short: add pets, change the background, and throw a ball. Those three links are the entire feature summary, and each one points into the generated site under docs/.

## The panel can be a sidebar view or a webview panel

The manifest contributes a view with the id petsView into the explorer container, typed as a webview, with its own icon and a localized title. The gating condition is a configuration key rather than a context value: the view appears only when vscode-pets.position equals explorer.

So panel placement is a setting, and the manifest supports two placements. Inside the Explorer sidebar it is one more item under your files. Outside it, the onWebviewPanel event for petCoding covers the alternative, a full panel that takes its own space next to the editor.

The pairing with the activation events explains itself: the view events wake the extension when you click the sidebar item, while onStartupFinished keeps it resident so a pet can move and react without the sidebar being in focus. The theme is a separate command from the placement, so background choice and panel position are decided in different places, and the README's own links treat them as two different pages on the documentation site.

## A browser entry point sits next to the desktop one

The manifest declares two entry points. main points at ./out/extension/extension.js for a normal VS Code install, and browser points at ./dist/web/extension-web.js for the web build. Both exist in a TypeScript project whose tsconfig set covers the same split: tsconfig.extension.json, tsconfig.panel.json, tsconfig.test.json and tsconfig.web.json.

The build setup is visible too. webpack.config.js handles bundling, four separate tsconfig files keep the extension host, the panel, the tests and the web target apart, and a script named upgrade.py sits at the repository root for version bumps, which is a Python tool in a TypeScript project.

Against that, the manifest's own version is 1.36.0 and the engine requirement is a single line: VS Code 1.73.0 or newer. That floor is over three years below the current release of the extension itself, so the extension is not tracking recent VS Code APIs. It is also why the four build targets matter: a web extension has fewer APIs available, and the browser bundle is the one that has to work without them.

## Fifteen translated bundles, synced from Crowdin into the tree

Localization is set up two ways at once. The manifest points l10n at a directory, and alongside it sit fifteen package.nls bundles covering cs, de, en, es, fr, hu, it, ja, ko, pl, pt-br, ru, tr, zh-cn and zh-tw. View titles and other user-facing strings are referenced through keys such as %vscode-pets.panel.title% rather than written inline.

The translation workflow is a single configuration file, crowdin.yml, plus a hosted project. The README states that the Crowdin project is synced automatically to the repository, and that a new language is requested through the discussions section on that project rather than through a pull request against the code.

That division of labour has a consequence worth knowing before you contribute a language. Translators work in Crowdin and the strings arrive by sync, so a pull request that edits the nls bundles directly can be overwritten by the next sync. The repository has a dedicated l10n directory for exactly this reason: strings live in one place, and the bundles are generated from it.

## The marketplace link carries a campaign parameter

The install section offers three routes: the marketplace listing, searching for vscode-pets in the extension panel, or pasting a command into Quick Open.

```bash
ext install tonybaloney.vscode-pets
```

The marketplace URL is not clean. It ends with a query string carrying a campaign identifier, WT.mc_id=python-17801-anthonyshaw, which is a tracking parameter left in the documentation rather than in user configuration. It affects nothing about the install itself, but it is the kind of detail that survives in a README for years because nobody opens the link in a text editor often enough to notice it.

The extension identifier is the same in all three routes: tonybaloney.vscode-pets. What is not documented anywhere in the repository is the .vsix file, even though people search for it, and nothing in the install section explains how to produce one. Anyone needing an offline or pre-provisioned install is left with the extension identifier and the source tree.

## Conclusion

Install vscode-pets if you want a pet in the editor and do not mind an extension that loads on every startup, since the manifest registers onStartupFinished alongside its ten commands. Judge it on what you can inspect: the source is public, the manifest names every activation event, and the licence is MIT, so there is nothing hidden behind the install. Before you enable it in a work profile, check where you want the panel, because the view can live in the Explorer sidebar or in a webview panel, and check which VS Code build you are on, since the manifest requires 1.73.0 or newer and also carries a separate browser entry point. If you only need the documentation site, that part needs no extension at all.

## FAQ

### How do I install vscode-pets?

From the VS Code marketplace page, by searching for vscode-pets in the extension panel, or by pasting ext install tonybaloney.vscode-pets into Quick Open. All three routes install the same extension identifier, tonybaloney.vscode-pets.

### How do I use vscode-pets once it is installed?

Open the command palette and run the Start pet coding session command, whose id is vscode-pets.start. After that the extension adds pets, changes the background and throws a ball, and the README links to the documentation site for the full set.

### How do I add a background in vscode-pets?

Backgrounds are handled by the change-theme command, and the README links to the themes page on the documentation site. The themes are separate artwork contributions, including an original winter scene and a forest scene credited to named artists.

### Is vscode-pets safe to install?

The source is public, the licence is MIT, and the manifest declares all of its activation events, ten commands and two view entries, so the extension's entry points can be read before installing. What activates it is onStartupFinished, which loads it in every window whether or not you want a pet.

### What is vscode-pets?

It is an MIT licensed extension that puts a pixel pet in the VS Code window, a cat, a dog, a snake, a rubber duck or Clippy, with commands for starting a session, adding pets, throwing a ball and changing the theme.

### How do I add more pets in vscode-pets?

The spawn-pet command adds a pet to a running session, and the README links to a documentation page dedicated to adding additional pets. Ten commands are registered in the manifest, including delete-pet and remove-all-pets.

## Sources

- [License: MIT](https://github.com/tonybaloney/vscode-pets/blob/main/LICENSE)
- [Project website](https://tonybaloney.github.io/vscode-pets)
- [README](https://github.com/tonybaloney/vscode-pets/blob/main/README.md)
- [Releases](https://github.com/tonybaloney/vscode-pets/releases)
- [tonybaloney/vscode-pets on GitHub](https://github.com/tonybaloney/vscode-pets)

---

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