# Peacock tints a VS Code workspace so two editors stop looking alike

> Peacock is a MIT licensed TypeScript Visual Studio Code extension that changes the colour of a workspace, so multiple editor instances, Live Share sessions or remote windows can be told apart at a glance. It suits anyone running several VS Code windows, and it only works inside a saved workspace.

**johnpapa/vscode-peacock** — Subtly change the color of your Visual Studio Code workspace. Ideal when you have multiple VS Code instances, use VS Live Share, or use VS Code's Remote features, and you want to quickly identify your editor.

- Repository: https://github.com/johnpapa/vscode-peacock
- Stars: 1,185 · Forks: 156
- Language: TypeScript
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/johnpapa-vscode-peacock

## The problem is two identical-looking windows, not a lack of themes

Peacock's description is precise about the problem it solves. It subtly changes the color of your Visual Studio Code workspace, and it is ideal when you have multiple VS Code instances, use VS Live Share, or use VS Code's Remote features, and you want to quickly identify your editor.

That is a narrow problem, and it is the kind of problem that only appears once you are working at a scale where a screenshot is ambiguous. Two windows, one on a local checkout and one in a container, both showing a README, both looking identical, and a colleague asking which one you mean. A coloured title bar and status area answers it in a glance without any window management.

The word subtly is doing real work in the description. Peacock is not a colour theme. It does not change the editor's syntax colours or the icon set. It tints the workspace, and the README's screenshots are of the frame rather than the content. That is what makes it usable alongside whatever theme you already have, and it is why the extension is listed under the Theme, Colors and Fun keywords with a single category of Other.

The Live Share and Remote cases are the two worth calling out. In a Live Share session, the host and the guests are in the same conceptual workspace but on different machines, and colouring the workspace by project or by role gives each participant an immediate cue. With Remote features, a VS Code window is attached to a remote host, and the local window and the remote window look the same, which is exactly the situation where a tint earns its keep.

The extension is written in TypeScript, is published by johnpapa on the Visual Studio Marketplace as johnpapa.vscode-peacock, and the README points to extensive documentation hosted on GitHub Pages including a guide and a changelog.

## A workspace file is required, and the commands live in the palette

The quick usage in the README is five steps, and the first one is a hard requirement rather than a suggestion.

You create or open a VS Code Workspace, and the README is explicit that Peacock only works in a Workspace, with a link to the troubleshooting entry for Peacock commands not appearing. Then you press F1 to open the command palette, type Peacock, choose Peacock: Change to a favorite color, and pick one of the pre-defined colors to see the editor change.

A user who opens a folder rather than a workspace will find that the commands do nothing, which is exactly the confusing case the documentation link points at.

The command list in the package manifest shows how the surface has grown. There is peacock.docs to open the documentation, peacock.resetWorkspaceColors, peacock.removeAllColors for removing all global and workspace colors, peacock.saveColorToFavorites, peacock.enterColor for choosing a custom colour, and a set of peacock.changeColorTo... commands for the named presets, one of which is peacock.changeColorToPeacockGreen. Every command carries the Peacock category so they group together in the palette.

The favourite-colour workflow is the part that makes the extension usable daily. Setting a colour once, saving it to favourites, and then applying it from the palette is a two-keystroke operation, and the reset and remove commands exist because you will need to undo a colour you applied to the wrong workspace.

## Two bundles, a UI extension and a workspace extension

The package manifest holds the technical decisions, and two of them are worth explaining because they explain how the extension is built and shipped.

The first is the dual entry point. The main field points at./dist/extension-node.js and the browser field at./dist/extension-web.js, so the extension ships a Node build and a web build. That is what lets Peacock run in VS Code in the browser rather than only in the desktop application. The webpack.config.js at the repository root and the vsc-extension-quickstart.md file are the scaffolding for that.

The second is extensionKind, which lists both ui and workspace. An extension that declares both can be loaded in either position, and the choice matters here because the extension has to write colour settings that follow the workspace across the local and remote boundary, and it also has to talk to the user interface to apply the colours immediately.

The activationEvents list contains a single entry, *, which means the extension activates on any VS Code event rather than on a specific command. For an extension whose whole job is to apply a colour that is already configured, that is the correct choice: the colour has to be there before you look at the window, not after you run a command.

The engine requirement is ^1.49.0, which is a useful number for anyone running an older VS Code. The rest of the manifest is conventional: the icon at resources/peacock-icon.png, a gallery banner with the colour #373436 and a dark theme, and preview set to false so the extension is generally available rather than limited to extension authors.

## Testing spans unit tests, Playwright end-to-end runs and a test workspace

The repository layout shows a testing setup that is more thorough than a colour extension strictly needs, and that is the point of looking at it.

There is a vitest.config.mts at the root, so the unit tests run under Vitest, and a playwright.config.ts for the end-to-end tests. The e2e/ directory holds those browser-driven tests, and the testworkspace/ directory holds a ready-made workspace for them to run against. A colour extension that only works inside a .code-workspace file needs exactly such a fixture to test, and having one checked in means the end-to-end suite has a realistic environment.

The scripts and docs directories carry the rest. The docs/ directory is the source for the GitHub Pages documentation site, and there is a separate workflow for it, so the documentation is published by CI rather than by hand. The .husky/ directory holds the git hooks, and the .prettierrc.js, eslint.config.js and tsconfig files cover formatting, linting and the TypeScript configuration, with a separate tsconfig.eslint.json.

The repository also has an .mcp.json file and a .claude/ directory, which are configuration for AI coding assistants, alongside AGENTS.md as the project guide covering architecture, patterns and how to add commands and settings. The README's contribution section is unusually direct about the intended route. It says the fastest way to contribute is with Copilot CLI, which it says knows the repository's conventions automatically, and gives a worked example:

```
copilot "Add a new command called 'Change to a Seasonal Color' that picks a color based on the current season"
```

Or you can contribute manually, following CONTRIBUTING.md: fork the repository and create a branch, run npm install, make your changes and run npm test, then open a pull request.

The example prompt is a good description of the extension's feature shape as well. Adding a new named colour is a small, self-contained contribution, and the contribution path is designed to make that easy for a first-time contributor.

## Modern UI compatibility was a real bug, and it is fixed upstream

The README's Problems or Suggestions section carries a note that is more interesting than a bug report usually is. The workbench.experimental.modernUI compatibility was fixed upstream in VS Code, and Peacock colors now apply normally with it enabled, with a link to issue 652 for the history.

That tells you two things. First, the extension had a genuine compatibility problem with VS Code's experimental Modern UI, where the colours simply did not apply. Second, the fix was not in Peacock. It was made in VS Code, and Peacock picked it up. The extension's own README now states that Peacock works whether you are on VS Code's classic UI or the new Modern UI, with the same colors and the same experience, and it shows side by side screenshots of both.

This is a useful thing to know before you evaluate the extension, because the failure mode was silent. An extension that changes nothing looks identical to an extension that is not installed, and a user with the experimental flag enabled could have concluded that Peacock was broken rather than that VS Code's colour API needed work.

The README has a Works with Modern UI section with its own heading and a comparison table, which suggests the maintainer considered it worth calling out separately from the release notes rather than burying it in a changelog entry. The screenshots are in resources/, and the resources/ directory also holds the small peacock-icon-small.png that the README header uses.

The overall release record is steady. The recent tags are 4.5.1 on 2026-09-29, 4.5.0 on 2026-09-28 and 4.4.1 on 2026-09-07, and the repository is not archived with the last push on 2026-10-04. The version in package.json is 4.5.1, matching the newest tag.

## MIT licensed, one author, and a marketplace distribution

The licence is MIT, with the LICENSE.md file in the repository as the authoritative text, and this is a licensing statement rather than legal advice. The package.json records the licence field as SEE LICENSE IN LICENSE.md, which is the form used when the licence text lives in a file rather than being a standard identifier.

The distribution model is the Visual Studio Marketplace, where the extension is published as johnpapa.vscode-peacock, and the README links the marketplace listing, the docs on GitHub Pages, the CI workflow and the docs workflow as separate GitHub Actions pipelines. There is a SECURITY.md for reporting vulnerabilities, which matters more than usual for an extension with broad activation, since it runs in every VS Code window you open.

The attribution setup is worth noting. The README carries an all-contributors list with entries for people who contributed code, tests, design, and ideas, planning and feedback, and the .all-contributorsrc file at the root drives it. So while the extension has one publisher and one primary maintainer, the contribution record shows it is a community project in the small-extension sense.

The README also credits the VS Code team and their guide for creating extensions, along with the extension samples repository, which is a common acknowledgement for extensions that followed the official getting-started path.

The two things to take away for an evaluation are small. The extension is a single-purpose tool that does one thing and does it across the classic and modern UI, and its maintenance is visible and current, with three releases in September 2026 and a push in October. The one functional constraint to check before you rely on it is the workspace requirement, since a folder-based session will not show the commands at all.

## Conclusion

Adopt Peacock if you regularly run more than one VS Code instance, share a Live Share session, or work against several remote hosts and need to know at a glance which window is which. Do not expect it to theme the editor, since it only tints the workspace chrome, and do not use it in a single-folder session, because the README says Peacock only works in a Workspace. Before you install, create or open a workspace file, and read the documentation, because the colour scope, whether it applies globally or per workspace, is configurable and matters for how you set it up.

## FAQ

### How do I install Peacock for Visual Studio Code?

Open the Extensions side bar panel in Visual Studio Code, choose View then Extensions, search for Peacock, click Install, and click Reload if required. The extension is published on the Visual Studio Marketplace as johnpapa.vscode-peacock.

### Why do the Peacock commands not appear in my command palette?

Peacock only works in a Workspace, so you need to create or open a VS Code Workspace rather than a single folder. The README links a documentation entry specifically about Peacock commands not appearing, and the extension needs a workspace file for its colour settings to live in.

### How do I change the workspace color in Peacock?

Press F1 to open the command palette, type Peacock, choose Peacock: Change to a favorite color and pick one of the pre-defined colors. There are also commands to choose a custom colour, save the current colour to favourites, reset the workspace colours, and remove all global and workspace colours.

### Does Peacock work with the new VS Code Modern UI?

Yes. The README states that Peacock works whether you are on the classic UI or the new Modern UI, with the same colors and the same experience. The workbench.experimental.modernUI compatibility was fixed upstream in VS Code rather than in the extension, and issue 652 has the history.

### What is the latest version of Peacock and how do I contribute to it?

The recent releases are 4.5.1 on 2026-09-29, 4.5.0 on 2026-09-28 and 4.4.1 on 2026-09-07, and the extension is MIT licensed. To contribute manually, fork the repository, create a branch, run npm install, make your changes, run npm test and open a pull request.

## Sources

- [Issues](https://github.com/johnpapa/vscode-peacock/issues)
- [johnpapa/vscode-peacock on GitHub](https://github.com/johnpapa/vscode-peacock)
- [License: MIT](https://github.com/johnpapa/vscode-peacock/blob/main/LICENSE)
- [README](https://github.com/johnpapa/vscode-peacock/blob/main/README.md)
- [Releases](https://github.com/johnpapa/vscode-peacock/releases)

---

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