A browser-based internal AI development platform with isolated employee workspaces, controlled model access, usage budgets, and operational safeguards.
Independent product prototype by Bryan Li. It integrates OpenVSCode Server and OpenAI Codex but is not an official OpenVSCode, Gitpod, or OpenAI product. See
UPSTREAM.mdfor attribution and scope boundaries.
Giving one developer a local AI coding tool is easy. Giving a team access without sharing model keys, raw IDE tokens, state, or usage budgets is a product and operations problem.
This repository turns an OpenVSCode container into a managed employee workspace: each user gets an isolated workspace and Codex home, enters through an access-code portal, sends model traffic through a gateway, and can be provisioned, disabled, budgeted, and audited by an operator.
The project demonstrates how I move from “install an AI tool” to a system that an internal team could pilot responsibly.
| Decision | Why it matters |
|---|---|
| One workspace and Codex home per employee | Prevent project files, sessions, and agent context from leaking across users. |
| Access-code portal instead of sharing raw IDE URLs | Gives operators a revocable product entry point while keeping connection tokens internal. |
| Model gateway instead of distributing provider keys | Centralizes credentials, usage attribution, budget checks, and upstream routing. |
| Secret files instead of committed environment values | Keeps real keys out of Git, process arguments, and generated workspace configuration. |
| Loopback binding by default | A local pilot should not silently expose browser IDEs to the LAN. |
| Explicit CPU, memory, PID, and soft workspace quotas | Makes team capacity and failure modes visible before a server rollout. |
- This is a pilot architecture, not a claim of internet-scale multi-tenancy.
- Local SQLite and a single management process are appropriate for validation, not for a globally distributed control plane.
- Workspace disk limits are soft checks on the current bind-mount setup.
- The platform does not modify or claim ownership of OpenVSCode or Codex.
flowchart LR
U[Employee] --> P[Access-code portal]
A[Operator] --> C[Admin console]
P --> I[Per-user OpenVSCode container]
C --> I
I --> W[Isolated workspace]
I --> H[Isolated Codex home]
I --> G[Model gateway]
G --> B[Budget and usage ledger]
G --> M[Upstream model API]
S[Secret files] --> G
C --> B
- Per-user OpenVSCode containers, ports, workspaces, Codex homes, and data volumes.
- Access-code login portal and operator admin console.
- Employee provisioning, enable/disable, start/stop, and quota controls.
- Model gateway with user attribution, token estimates, budget checks, and upstream proxying.
- Generated connection tokens and file-based model-secret management.
- Secret rotation workflows for local and server environments.
- CPU, memory, PID, concurrency, and workspace-quota checks.
- Windows pilot supervision plus Linux systemd and Nginx deployment templates.
- Custom project-launcher and product-workbench extensions.
- A default product-research workspace demonstrating multi-agent knowledge synthesis.
The product treats the coding agent as part of the operating model, not a chat widget. Each user receives persistent project context and Codex state inside an isolated environment; the product workbench turns research, product decisions, implementation, and verification into visible workflow stages.
I also used coding agents while building the platform, but kept the durable system knowledge in versioned scripts, tests, product documentation, security defaults, and deployment templates. A new operator should not need a private conversation transcript to understand the system.
My work is the orchestration and product layer in this repository: portal, gateway, provisioning, resource and budget controls, secret handling, custom extensions, deployment templates, tests, and operating model.
OpenVSCode Server provides the browser IDE runtime through the public
gitpod/openvscode-server container image. OpenAI Codex is installed as an
extension/runtime dependency. The unused upstream OpenVSCode source snapshot
was removed from the current branch so the visible code represents this
project's contribution rather than millions of upstream lines.
| Check | Result in a clean source checkout |
|---|---|
| Product/orchestration Node checks | 10 passing files |
| Portal, gateway, admin, and security Python tests | 18 passing tests |
| Source snapshot dependency audit | Runtime uses the container image; no local source-tree dependency |
| Secret scan | No committed live model or connection credential found |
| Optional VSIX artifact validation | Runs only after local binary artifacts are downloaded or packaged |
The VSIX artifact test is intentionally not included in source-only CI because
extensions/*.vsix is ignored and binary packages are not committed.
portal/app.py: access portal, admin console, persistence, budget logic, and model gateway.scripts/: provisioning, startup, supervision, quotas, secret rotation, and deployment automation.extensions/product-workbench/: product-delivery workflow inside the IDE.extensions/project-launcher/: safe project discovery and container-path mapping.deploy/: Nginx and systemd server templates.test/: portal, gateway, security, operations, and portability checks.docs/product-description.md: detailed product and operations documentation.workspace/pick-demo/: demonstration of structured product-research synthesis.
Requirements: Node.js 22+ and Python 3.12+.
$nodeTests = @(
'extensions/product-workbench/test/workflowModel.test.js',
'extensions/project-launcher/test/projectCatalog.test.js',
'test/accessPortalScripts.test.js',
'test/autoBootstrap.test.js',
'test/codexPermissionDefaults.test.js',
'test/defaultWorkbenchExperience.test.js',
'test/operationsReadiness.test.js',
'test/powershellDownloadPortability.test.js',
'test/secretManagement.test.js',
'test/serverDeployment.test.js'
)
node --test $nodeTests
python -m unittest discover -s test -p '*_test.py'The detailed Windows and server runbooks live in
docs/product-description.md. The shortest safe
pilot path is:
- Install Docker Desktop and clone the repository.
- Store the upstream model key through the provided secret-management script.
- Start the management portal.
- Provision an employee with a unique port and access code.
- Give the employee only the portal URL and their code—not the raw IDE token.
Generated .env.local, .portal/, .secrets/, .instances/, and .artifacts/
paths are ignored by Git.
Start the management plane with scripts/start-management.ps1, then create an
employee identity with scripts/provision-access-user.ps1. The provisioning
flow starts the user's isolated container, configures the model gateway, stores
the launch target, and writes a one-person access code under ignored artifacts.
The employee receives the portal URL and access code. The raw OpenVSCode connection URL and gateway credentials remain operator-only.
scripts/install-management-service.ps1installs local supervision.scripts/run-management-supervisor.pyrestarts the management process and records logs.scripts/run-pilot-concurrency-check.ps1probes 5, 10, or 20-user pilot capacity.scripts/check-instance-quotas.ps1reports workspace usage against configured soft limits.- Container defaults enforce CPU, memory, and PID ceilings.
Real model credentials live in ignored files mounted read-only into the
container and gateway. Rotations write fingerprints—not raw values—to
secret-audit.jsonl. Use scripts/rotate-model-secret.ps1 for the Windows
pilot or scripts/rotate-server-model-secret.sh on Linux.
The gateway associates usage statistics with an employee identity so operators can inspect consumption and apply budgets without distributing the provider key.
scripts/start-server-instance.sh creates isolated instance state beneath
/srv/openvscode-codex and launches Docker Compose with generated connection
tokens and file-backed model secrets. Reverse-proxy and service templates are
provided under deploy/; they are starting points that still require
host-specific TLS, firewall, backup, and observability configuration.
- Replace the local control plane with a durable service before a multi-host rollout.
- Add an organizational identity provider and stronger user lifecycle integration.
- Replace estimated model usage with provider-confirmed metering where available.
- Move from soft workspace checks to storage-level quotas on the production host.
- Pin and routinely update the OpenVSCode image digest rather than relying on
latest. - Add production observability, backups, and disaster-recovery exercises.
这是一个面向内部团队的浏览器 AI 编程工作台原型。我负责的不是 OpenVSCode 或 Codex 本身，而是让它们能够被团队安全使用的产品层：员工入口、实例与数据隔离、模型网关、密钥管理、用量与预算、管理员操作、资源限制和部署验证。它体现了我把 AI 工具进一步产品化、平台化并落到实际协作流程中的能力。