Pascal Editor: one active agent client per local scene

The local CLI starts an MCP service and picks its own loopback ports

Pascal Editor runs in a browser or from the command line, and the CLI path is the more unusual of the two. Node.js 22.23.4+ on 22.x, 24.22.1+ on 24.x, or 26.12.1+ is enough to create a persistent local installation without cloning the repository:

npx @pascal-app/cli editor

What that one command starts is more than an editor. It launches the editor and an authenticated MCP service in the background, selects collision-free loopback ports, and keeps projects in ~/.pascal/data/pascal.db. Projects therefore persist locally in SQLite rather than living in an account.

The npm package holds the CLI and that MCP service. The web editor runtime is a separate download, pulled once per version on the first command that starts the editor, and verified against a digest published inside the package. An agent that only needs tools can run pascal mcp connect, which needs neither the editor process nor that runtime download.

Installing the command itself is a distinct step:

npm install --global @pascal-app/cli

One active agent client per service, because scene state is shared

There is a concurrency rule here that is easy to miss and expensive to violate: use one active agent client per local CLI service. The reason is architectural rather than advisory. The standalone local HTTP runtime shares active scene state between clients, so a second agent connecting to the same service is not receiving an isolated copy of the project. It is attaching to the same scene that is already open.

When genuinely independent concurrent work is required, the documented answer is separate PASCAL_HOME directories and separate service processes. That means extra services, extra port sets and extra project stores, which is more machinery than most people expect from a local editor.

If you plan to run agents in parallel against a Pascal project, decide up front whether they deliberately share a service or get one each.

Two MCP servers ship in one plugin, and both can be active at once

The plugin bundles two MCP servers. One is the local pascal connector supplied by pascal mcp connect, which needs no Pascal account and no API key and does not upload projects automatically. The other is a hosted pascal-hosted server pointing at the editor API endpoint, which prompts for an optional Pascal API key when it is enabled and stores that key in the OS keychain. Leaving the key empty runs you local-only.

Claude Code 2.1.258 loads both the user-scoped pascal server created by pascal mcp setup claude and the plugin-provided one. The documented fix is to remove the manual entry before reloading or restarting:

claude mcp remove --scope user pascal

Project-scoped and local-scoped connections can be removed or disabled from the /mcp menu. The stated reason to care is the one-active-agent-client rule: leaving both connections active violates it. When a project is hosted in a Pascal account or organization, the guidance inverts, and you disable the plugin's local server in /mcp and configure the hosted endpoint from the skill setup guide instead.

A capability in the repository is not a capability on your server

There is a version skew caveat that the project states plainly and that is worth taking seriously. The skills inspect the connected MCP tool schemas before using optional fields, because a capability present in this repository may be absent from an older installed or hosted release. When that happens the agent is instructed to report the narrower supported result instead of assuming a source-only input is available.

The consequence is that debugging an agent failure here can send you down the wrong road. If a tool field comes back rejected, the first question is not whether the repository supports it but which release your connected server is actually running, and whether that is an older hosted deployment. Check the connected server before concluding that a skill is wrong.

Remapping the host port 500s the scenes page, and dropping the volume loses projects

Two container failure modes are documented in the files themselves, and both are the kind you would rather read about in advance.

The first is the password. The compose file maps ${PORT:-3000} to container port 3000 and requires PASCAL_ADMIN_PASSWORD; its comment says the password is required on any host that is not loopback, and without it the app serves a setup page and nothing else.

The second is data loss. The compose file mounts a named pascal-data volume at /data, which its comment calls the scene database location. The comment is blunt about the alternative: without that volume, every saved project is discarded when the container is recreated. The service also sets restart to unless-stopped, so a crash loop comes back up against the same volume and will not clear your projects either.

The image installs a real node because Next 16's build crashes on the bun shim

The Dockerfile is built on oven/bun:1.4.4-alpine, and it carries unusual commentary about what breaks. The base image's node is a shim that re-execs bun, and Next 16's build crashes under it: a segfault on 1.3.14, a turbopack CommonJS wrapper error on 1.3.0, on both arm64 and amd64. CI never encounters this because GitHub runners have a real node. The fix inside the image is a single line adding a genuine nodejs package:

RUN apk add --no-cache 'nodejs>=24.22.1-r0'

The image also notes that its Bun version must match the packageManager field in package.json and the version CI installs, because a skew there is what makes a frozen lockfile install fail inside the image while succeeding on a developer machine.

The practical read is that the container build is sensitive to two things people forget: the node shim, and lockfile version drift. If the editor image fails to build with a crash rather than a type error, suspect the runtime before your own code. The build is scoped with turbo run build filtered to the editor package.

The hosted demo shows rooms, light and doors, none of it in the release

The most misleading thing about this project is its demo. The hosted preview shows a home reconstructed in detail, from its rooms and finishes through to the structure and systems behind the walls, with exploded, cut, X-ray, walkthrough, interaction and environment views. It reads like the product. It is not, and the project says so directly: that hosted preview explores the direction of the next Pascal editor, and the experience shown there is not yet part of the open-source editor release.

So what those views demonstrate, opening doors, changing the light and atmosphere, stepping inside at eye level, is roadmap rather than inventory. The open-source editor is built with React Three Fiber and WebGPU, and the repository description says node renderers are React components that create Three.js objects for each node type.

Maintenance itself is active. The repository is not archived, the last push landed on 2026-11-02, and the latest release is @pascal-app/[email protected], published on 2026-10-23.

Editorial conclusion

Use Pascal Editor if you want a browser or CLI 3D building tool where agents drive it over MCP and your projects stay in a local SQLite file. Stay away if you need the walkthrough, lighting and door interactions from the hosted preview, because those are explicitly not in the open-source release yet. Before wiring agents up, confirm only one client per local service, check whether you have both the local and hosted MCP servers enabled, and give each concurrent job its own PASCAL_HOME. When self-hosting, set PASCAL_ADMIN_PASSWORD and keep the pascal-data volume, or saved projects are discarded when the container is recreated.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes