# Claw3D: a self-hosted 3D office where AI agents do visible work

> A TypeScript and WebGL front end that connects to an agent runtime over a small gateway contract and renders your agents as workers in a 3D office you run yourself.

**iamlukethedev/Claw3D** — Claw3D is an open source 3D engine built on OpenClaw for creating games, simulations, and high-performance 3D applications.

- Repository: https://github.com/iamlukethedev/Claw3D
- Website: https://claw3d.ai
- Stars: 2,265 · Forks: 620
- Language: TypeScript
- License: MIT
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/iamlukethedev-claw3d

## What Claw3D is, and what it refuses to be

Claw3D is easiest to understand by what it is not. The repository is not a model, not an agent framework, and not an orchestrator. It does not build the upstream runtimes. It is the frontend, the Studio settings layer, and the adapter and proxy tier that connects to something already speaking the Claw3D gateway protocol.

What sits on the other end of that connection is a runtime, and Claw3D currently speaks to four kinds. There is OpenClaw through the existing gateway flow, Hermes through a bundled WebSocket adapter, a direct HTTP provider labelled custom for orchestrator-backed stacks, and a built-in demo gateway that lets you walk through the office with no agent framework installed at all. That last option matters more than it sounds, because it separates evaluating the interface from evaluating an entire agent stack.

Once connected, the app gives you a /office surface where agents appear as workers moving through a shared 3D world, an /office/builder surface for editing and publishing office layouts, and a set of immersive operational rooms for standups, GitHub review flows, analytics, and system monitoring. Runtime state stays in the connected backend, while Studio persists local preferences: gateway connection details, focused-agent choices, desk assignments, and office state.

The project describes itself as a 3D virtual office for AI agents that you run on your own infrastructure, and it labels itself unofficial in the README, with no affiliation to or endorsement from the OpenClaw team. For something sitting on top of another project's runtime, that is the correct posture to state up front rather than discover later.

## Getting it running locally

The quick start is five shell commands, and the README lists them as written.

```bash
git clone <your-public-repo-url> claw3d
cd claw3d
npm install
cp .env.example .env
npm run dev
```

Node.js 20 or newer and npm 10 or newer are the stated recommendations. After the dev server starts, Studio listens on http://localhost:3000 and you configure the gateway URL and token in the interface rather than in the environment file. That is a deliberate design choice: Studio persists the selected backend mode, covering OpenClaw, Hermes, Demo, Local, Claw3D, and Custom, and it displays whichever backend the connected gateway reports back. You get a visible answer to the question that otherwise costs an afternoon when something is wired incorrectly.

One prerequisite deserves to be stated plainly, because the README states it plainly. Claw3D does not install or build OpenClaw or Hermes for you. If you point it at a real backend, that backend must already be running and you must already know its gateway URL and token. If you only want to look around, the built-in demo gateway needs no agent framework, and the repository ships a full cross-machine setup guide covering OpenClaw with Tailscale and Claw3D in TUTORIAL.md.

The dev script is not a bare Next.js invocation. package.json points dev at a custom Node server, and a separate dev:https variant exists for people who need TLS locally.

## The gateway contract is small on purpose

Every part of Claw3D is arranged around a gateway boundary, and the direct HTTP path is the easiest one to integrate against. For a runtime plugged in through the custom provider, the README lists four expectations: a GET on /health, a GET on /state, a GET on /registry, and a POST on /v1/chat/completions. That is the whole contract. If your orchestrator can answer those four requests, it can drive an office.

The browser never calls that runtime directly. Claw3D proxies the custom provider through its own same-origin surface, which removes a class of CORS problems and gives auth and logging one place to live. A custom WebSocket proxy sits between the browser and Studio, and Studio talks upstream to the gateway.

Configuration lands at two different moments, and confusing them is a quiet source of breakage. NEXT_PUBLIC_GATEWAY_URL is baked in at build time and needs a rebuild after any change. CLAW3D_GATEWAY_URL takes effect on restart without a rebuild, and the shipped .env.example tells you to prefer the second when you want to move the endpoint around. An optional CLAW3D_GATEWAY_ADAPTER_TYPE tells Studio which kind of backend that URL represents, with openclaw, hermes, demo, and custom accepted.

Since v0.1.4 the single global URL and token pair has been replaced by named runtime profiles, each with its own saved URL and token, and the office gained a multi-floor model where one runtime binds per floor. The release notes name floors such as lobby, training, campus, and traders-floor, and add server-backed messaging and handoffs between remote offices through /api/office/remote-message and /api/office/remote-handoff.

## The stack under the office

The rendering choices are conventional, which is worth knowing before you start reading source. Claw3D is a Next.js application on React 19.2.3 with Next pinned to 16.1.7. The 3D layer is three 0.183.2 with @react-three/fiber 9.5 and @react-three/drei 10.7. Phaser 3.90 sits alongside for the more game-like surfaces, lucide-react handles icons, ws 8.18 provides the WebSocket side, and @noble/ed25519 covers signing. Styling runs on Tailwind 4.

The image build is a three-stage Dockerfile on node:20-slim, and the runner stage looks like this.

```
FROM node:20-slim AS runner
WORKDIR /app
ENV NODE_ENV=production
ENV NEXT_TELEMETRY_DISABLED=1
```

That stage copies the built .next directory, the public assets, the server directory, and a production-only node_modules taken from a separate dependency stage, then starts node server/index.js and exposes port 3000. The build stage sets a default WebSocket gateway URL that the runtime overrides, which enforces the same build-time versus runtime split as the env file, this time at the image level.

A few details in package.json say more about how the project is worked on than the feature list does. Beyond dev and build, the scripts include a hermes-adapter entry point, a demo-gateway entry point, a doctor script for diagnostics, a smoke test for the dev server, a sync step for the gateway client, a typecheck wired to tsc --noEmit, Vitest for units, and Playwright for end to end runs. The package is marked private at version 0.1.4, so installation happens from a clone rather than from a registry.

## What the 0.1.x releases actually changed

The release history is short and reads like a product search in progress. v0.1.2 on 2026-03-21 introduced customizable 3D avatars with persistent profiles and a unified agent editor that puts visual identity and agent brain configuration in one place. Its own notes call this an early version and warn to expect rapid iteration and breaking changes as the platform moves.

v0.1.3 on 2026-03-28 shifted the project from a single-office viewer toward a fuller workplace. It added an onboarding wizard, a packaged skills marketplace with trigger-driven office routing and starters such as Todo Board and SOUNDCLAW, an office agent management wizard, a multi-agent beta with presence sync and remote messaging, and a company builder that generates an organization with AI assistance. The same release hardened access control so gating applies across all routes rather than only under /api, closed path traversal and file path validation gaps in local file operations, and resolved symlink handling in path suggestions.

v0.1.4 on 2026-04-23 converged the runtime profile, office systems, and diagnostics work onto one branch. Alongside the named profiles and multi-floor model it brought local file uploads for chat attachments with allowlisted MIME types and a 10 MB cap, plus a claw3doctor diagnostics CLI that runs against a single profile or across all of them with an all-profiles flag.

The security portion of that changelog deserves a second read. File handling bugs and route gating are not glamorous entries, but they describe exactly the class of problem you inherit when you point a browser interface at a machine that holds agent sessions.

## Where the edges still show

A fair read of the current state is pre-1.0 with a long feature surface and a short track record. The repository carries 51 open issues, and the tree shows the marks of fast iteration, including scratch scripts such as get_angles.js, get_angles2.js, make_continents.js, test_coords.js, test_patches.js, and test_patches2.js sitting at the top level beside the application source rather than tucked into a tooling directory.

The documentation set is unusually complete for a project this young: ARCHITECTURE.md, VISION.md, TUTORIAL.md, ROADMAP.md, CHANGELOG.md, SECURITY.md, SECURITY_HARDENING.md, CONTRIBUTING.md, CODE_OF_CONDUCT.MD, a skills overview, a runtime profiles page under docs, and a MULTI_AGENT_BETA.md. Testing is wired up as well, with Vitest for units, Playwright for end to end work, two separate Playwright configurations including one dedicated to kanban, and a typecheck script.

For public or remote deployments the env file points at a STUDIO_ACCESS_TOKEN that is described as required only in those cases, and it also lists a batch of optional SSH settings for gateway host operations, noting that installing a marketplace skill does not need them. Voice features are optional too, gated behind an ElevenLabs key, model identifier, and voice identifier.

Practical order of operations: start from the demo gateway, decide whether the office metaphor earns its place in your workflow, and only then commit a real runtime. When that happens, claw3doctor is the first tool to reach for.

## Conclusion

Claw3D is worth an afternoon of your time if you have agent runs that currently only exist in logs. Clone it, start the bundled demo gateway, and judge the interface without any agent framework installed. The deciding factor for real use is not the rendering but the gateway contract, which is small enough to read in a minute: health, state, registry, and a chat completions endpoint. Two things to hold in mind as you go. The package is still at 0.1.4 with 51 open issues, and the v0.1.2 notes themselves warn to expect breaking changes through the 0.1.x line. And the security record matters: v0.1.3 closed path traversal and file path validation gaps in local file operations and extended access control gating to every route, so treat any Studio exposed beyond localhost as work in progress rather than a finished deployment.

## FAQ

### What is Claw3D?

Claw3D is a self-hosted web application that renders an AI agent runtime as a 3D office. Agents appear as workers moving through a shared world, and the app adds standups, GitHub review flows, analytics, and monitoring rooms on top. It is the visualization and interaction layer, not an agent runtime itself.

### Which runtimes can Claw3D connect to?

Four options today: OpenClaw through the existing gateway flow, Hermes through the bundled WebSocket adapter, a direct HTTP custom provider for orchestrator backed stacks, and a built in demo gateway that needs no agent framework. Since v0.1.4 each backend is saved as its own named runtime profile with its own URL and token.

### Does Claw3D install or build OpenClaw for me?

No. The repository does not build upstream runtimes. Before pointing Claw3D at a real backend, that runtime must already be running and you need to know its gateway URL and token. For a full cross machine setup the project ships TUTORIAL.md covering OpenClaw, Tailscale, and Claw3D together.

### Can I try Claw3D without installing any agent framework?

Yes. Run the bundled demo gateway with npm run demo-gateway and connect Studio to ws://localhost:18789. That path exists specifically so you can explore the office layout and interface without OpenClaw or Hermes present. It is also the quickest way to judge whether the office metaphor suits your workflow.

### What do I need before exposing Claw3D to a network?

Set STUDIO_ACCESS_TOKEN, which the env example marks as required only for public or remote deployments, and bind the app to the interface you intend to serve. Release v0.1.3 hardened access control across all routes rather than only under /api, and closed path traversal, file path validation, and symlink handling gaps in local file operations.

## Sources

- [iamlukethedev/Claw3D on GitHub](https://github.com/iamlukethedev/Claw3D)
- [License: MIT](https://github.com/iamlukethedev/Claw3D/blob/main/LICENSE)
- [Project website](https://claw3d.ai)
- [README](https://github.com/iamlukethedev/Claw3D/blob/main/README.md)
- [Releases](https://github.com/iamlukethedev/Claw3D/releases)

---

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