# The workspace editor Every DevPlace workspace opens a full editor in your browser. It is branded DevPlace, it starts a coding agent for you, and it is configured from your DevPlace account rather than from inside the editor. Open one from a project's **Workspace** page, or with the **Editor** button on the project itself once the workspace is running. ## What opens on boot When your workspace starts, two terminals open at the bottom of the window: - **DevPlace Code** runs [`dpc`](/docs/getting-started-vibing.html), the coding agent that ships in every workspace. It has focus, so you can type a request straight away. Every token it spends is metered against your own DevPlace account. - **pravda@workspace** is an ordinary login shell, so the Python, Rust, Nim and Swift toolchains are all on your `PATH`. New terminals you open later are plain shells. To start another agent, pick **DevPlace Code** from the terminal dropdown, or run the command **DevPlace: Start DevPlace Code**. The workspace opens straight onto your files with the terminal ready, not onto a welcome page, and the editor's own built-in chat assistant is switched off: `dpc` is the assistant here, and it runs on your DevPlace account. The files `dpc` keeps for itself (`.dpc/` and `dpc.log`) stay in the container and are never copied into your project. You can turn either of them off. See **Your preferences** below. ## Every workspace is trusted VS Code normally opens an unfamiliar folder in **Restricted Mode**, which disables tasks, debugging and most extensions until you click to trust it. DevPlace turns that off: your workspace is yours, so it is trusted from the first second and nothing prompts you. **This has a real consequence, and you should know it.** Automatic tasks are enabled too, so if a project you open contains a `.vscode/tasks.json` with a `"runOn": "folderOpen"` task, that task runs when the folder opens. If you are about to open code you did not write and do not trust, read that file first. An administrator can restore Restricted Mode for the whole site from the workspace service settings. ## Size Four separate things have a size, and they are set in two different places. | What | Set by | Where | |---|---|---| | Editor font size, terminal font size, zoom | You | Your workspace page | | Editor layout and terminal panel size | You | Your workspace page | | How the editor opens (tab or sized window) | You | Your workspace page | | CPU, memory and disk | An administrator | Your workspace quota | Your own preferences follow you into every workspace you open. The container size is part of your quota and is shown on the same page so you always know what you have. ## Your preferences The **Editor** card on your workspace page holds them all: - **Theme** - DevPlace Dark, DevPlace Light, or leave it to you (pick any theme from inside the editor and DevPlace will not touch it again). - **Layout** - Standard, Terminal focus, or Zen. - **Terminal panel** - Short, Normal, Tall or Maximized. - **Editor font size**, **Terminal font size**, **Zoom level**. - **Agent on boot** and **Shell on boot**. - **Open editor in** - a new tab, a sized window, or a fullscreen window, with the width and height for the sized case. Every field has a **Site default** option. Choosing it removes your preference and lets the administrator's value apply again, including any future change to it. **Reset to site defaults** does that for all of them at once. Over the API and through Devii the same rule applies field by field: only the fields you send are changed, and a field you send as empty or zero goes back to inheriting. ### They apply on the next start Editor settings are read when the workspace container boots. After you save, the page tells you if a restart is needed and gives you the buttons to do it. ### DevPlace never overwrites a setting you changed yourself If you change something inside the editor, that value is yours from then on. DevPlace only writes a setting it wrote itself last time, so a change to the site default reaches everyone who has not expressed an opinion and no one who has. ## Doing it from Devii Devii can read and change these for you: - *"what is my workspace editor set to"* runs `workspace_editor_get`. - *"make my workspace editor font 18 and use the light theme"* runs `workspace_editor_set`. It will show you the exact values and ask before saving. ## Commands inside the editor Press `F1` and type `DevPlace` for the full list: | Command | What it does | |---|---| | **DevPlace: Start DevPlace Code** | Opens another `dpc` terminal | | **DevPlace: Open project on DevPlace** | Your project page | | **DevPlace: Open workspace settings** | Your workspace page | | **DevPlace: Show public tunnels** | Pick one of your live public addresses | | **DevPlace: Open the DevPlace editor guide** | This page | ## Publishing a port from the editor Forward a port in the editor's **Ports** view and DevPlace publishes it for you. The moment you forward it, the editor registers the port with DevPlace, which creates the tunnel, orders its HTTPS certificate and answers with the public address - the same address the Ports view shows you. Publishing counts against your tunnel quota, so a port DevPlace refuses is reported back in the editor with the reason. Two things to know: - The address serves HTTPS as soon as the certificate is issued, which takes a few seconds. Until then your browser warns about the certificate name. - Un-forwarding the port in the editor does **not** remove the tunnel. Public addresses are removed deliberately, on your workspace page or by asking Devii, so a restarted dev server never silently loses its link. ## Related - [Get started with vibing](/docs/getting-started-vibing.html) - the container runtime, the agents, and publishing what you build. - The **Dev Workspaces** API group for the same settings over HTTP.