npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

codebay

v0.16.2

Published

Web UI for spinning up isolated devcontainer instances from any local folder, each with a browser-based VS Code (code-server) — built for parallel Claude Code workflows.

Readme

Codebay

Codebay - the devcontainer manager — a web UI for spinning up isolated devcontainer instances from any local folder or Git repo URL, each running Claude Code in a browser-based VS Code (code-server).

Quick start

Requires Bun >= 1.3.13 (Node.js is not supported) and a running Docker daemon (Docker Desktop, Colima, OrbStack…). macOS, Linux and Windows are supported.

On Windows, Docker Desktop must use its WSL2 backend, so the workspace copies under %USERPROFILE%\.codebay\ can be bind-mounted into the Linux daemon. Symlinks in a source folder are copied as regular files rather than recreated, because Windows only permits creating them under Developer Mode — the same thing Git for Windows does by default.

bunx codebay@latest

The UI opens at http://localhost:6969. State (SQLite DB + per-instance workspace copies) lives in ~/.codebay.

Configuration

  • PORT — server port (default 6969)
  • DATA_DIR — where state lives (default ~/.codebay)
  • DOCKER_HOST — Docker socket/URL (defaults to your active Docker context)
  • HOST — bind address (default 127.0.0.1). Set 0.0.0.0 to reach codebay from other machines; your instances' forwarded app ports are then published on all interfaces too. Each container's code-server port stays loopback-only regardless — it runs without a password of its own and is reached through the Basic-Auth-gated /p/:id/ proxy instead. Existing instances need a Restart to pick up the new binding. Note that a plain-http LAN address is not a secure context, so browsers refuse clipboard access there and copying out of an instance's VS Code terminal does nothing — reach codebay over localhost (e.g. ssh -L 6969:localhost:6969 <host>) or allow the origin under chrome://flags/#unsafely-treat-insecure-origin-as-secure.
  • PUBLIC_ORIGIN — the origin you actually load codebay from (default http://localhost:<PORT>). Every form POST — creating an instance, restarting one, saving settings — is checked against it, so reaching the UI at any other address (a LAN IP, a hostname, or a reverse proxy / tunnel that terminates TLS) makes those actions fail with a 403 Cross-site POST form submissions are forbidden until you set this. Give the exact scheme + host + port your browser shows, with no trailing slash — PUBLIC_ORIGIN=http://192.168.1.50:6969 or PUBLIC_ORIGIN=https://codebay.example.com. Behind a TLS-terminating proxy this is the public https:// URL, not the loopback address the proxy forwards to.
  • TRUSTED_ORIGINS — comma-separated extra origins accepted alongside PUBLIC_ORIGIN, for when the UI is legitimately reachable at more than one address (e.g. http://localhost:6969,http://192.168.1.50:6969)
  • BASIC_AUTH_PASSWORD — enables HTTP Basic Auth over the whole UI (disabled when unset); required if you bind beyond loopback with HOST=0.0.0.0
  • CODEBAY_CLAUDE_CODE_TOKEN — Claude Code token to inject into every container (e.g. from claude setup-token) instead of discovering the host's credentials
  • CODEBAY_GITHUB_TOKEN — GitHub token to inject instead of reading gh auth token from the host
  • DISABLE_OPEN_BROWSER=1 — skip opening the browser on startup

MCP server

Codebay can expose itself to other AI agents over MCP, so an agent can spin up a sandbox, run Claude Code in it non-interactively, and read back the result.

It is off by default. Turn it on under Settings → MCP server, then copy the registration line it shows you:

claude mcp add --transport http codebay http://localhost:6969/mcp \
  --header "Authorization: Bearer <token>"

The endpoint is /mcp. It returns 404 while disabled and 401 without a valid bearer token, and it is the one place that does not use BASIC_AUTH_PASSWORD — MCP clients send the token instead.

The tools cover the whole loop: create_sandbox, run_agent, get_run, list_runs, stop_run, get_diff, read_file, write_file, exec_command, git_push, create_pr, get_logs, list_sandboxes, get_sandbox, rename_sandbox, stop_sandbox, start_sandbox, rebuild_sandbox, add_port_forward, remove_port_forward and delete_sandbox. Runs are asynchronous — run_agent hands back a run id and the work continues in the background, surviving a manager restart. stop_sandbox / start_sandbox cycle the container without losing the workspace, and rebuild_sandbox recreates it (which is what applies a port forward).

Sandboxes created this way are ordinary instances: they show up on the dashboard with a live "agent running" line, and you can open the IDE to watch. They persist until an agent (or you) deletes them.

Anything holding the token can create containers and run agents with your GitHub and Claude credentials, with permission prompts bypassed inside the container. Treat it like a password, and regenerate it from Settings if it leaks.

Workspace uploads

Turn on Settings → Drop files into the workspace to drag-and-drop or paste files/images onto an instance and save them under codebay-inbox/ in its workspace (git-excluded), so Claude Code inside can Read them. Off by default.

Troubleshooting

  • 403 Cross-site POST form submissions are forbidden when clicking anything that saves — codebay is being reached at an origin other than http://localhost:<PORT>. Set PUBLIC_ORIGIN to the URL in your browser's address bar and restart (see Configuration).
  • warn: incorrect peer dependency "[email protected]" on startup — harmless. It comes from svelte-french-toast, whose published peer range predates Svelte 5; the library works correctly on Svelte 5. Nothing to fix.

Development

bun install
bun run dev        # dev server, local ./.codebay DATA_DIR, no browser launch
bun run checks     # format + typecheck + tests

The repo also ships a Bun devcontainer (.devcontainer/) for a containerized setup; it runs a nested Docker daemon, so codebay itself can boot instances from inside it. New to authoring devcontainers? See the general Devcontainer guide.

License

MIT