Normalizes non-standard code-fence language tags across `docs/**` so a strict highlighter (Shiki, used by Fumadocs) won't fail the build on an unrecognized language, and unifies redundant synonym tags onto one canonical form per language. The current renderer (Speed-Highlight) detects the language from the code content, not the fence label, so this drift wasn't visible until now. ## Changes - `hcl` -> `tf` (199 fences, including indented ones nested in numbered/bulleted lists). Shiki ships `hcl` and `terraform` as two distinct grammars (not aliases); every `hcl`-tagged fence in `docs/**` is actually Terraform resource/data/provider syntax, so the more specific `terraform` grammar is correct for all of them. `tf` is Shiki's own alias for that grammar, and it's also what GitHub's own markdown renderer resolves to the same HCL/Terraform highlighting. - `pwsh`/`powershell` -> `ps1`. Both `ps` and `ps1` are registered PowerShell aliases in Shiki, but on GitHub's renderer only `.ps1` is a registered file extension (`.ps` isn't), so `ps1` renders identically to `powershell` there today while bare `ps` would silently lose highlighting. - `env` -> `dotenv` (a dedicated Shiki grammar for `KEY=VALUE` files) - `text`/`output`/`none`/`url` -> `txt`. Same built-in plain-text fallback either way, just shorter. - `Dockerfile` -> `dockerfile` (lowercase) - `bash`/`shell` -> `sh` (732 fences). Shiki and GitHub both alias all three to a single shell grammar; this was already the style guide's stated preference, just not enforced across the existing corpus until now. - `markdown` -> `md` (4 fences). Alias of the same grammar in both Shiki and GitHub. - `jsonc` -> `json` (1 fence). The block has no comments or trailing commas, so it doesn't need the comments-capable grammar. - `ts` -> `tsx` (2 fences, `docs/about/contributing/frontend.md`). Verified the actual content tokenizes identically under both grammars, and a sibling block in the same file already needs `tsx` for real JSX, so unifying to one tag is safe for this file. Documented a caveat: `tsx` mis-tokenizes the legacy angle-bracket type-assertion syntax (`<Type>value`), which is invalid in real `.tsx` files anyway, so use `value as Type` instead. - `yml` -> `yaml` (1 fence) - Updated `docs/.style/style-guide/formatting.md` to document all canonical tags `promql` (2 fences) and `caddyfile` (2 fences) are left as-is. Shiki doesn't bundle a grammar for either, so they need a custom grammar registration when the site adopts Shiki, rather than degrading to `txt`. Tracked as follow-up work under DOCS-118 and [DOCS-544](https://linear.app/codercom/issue/DOCS-544/vendor-a-local-promql-grammar-for-shiki-syntax-highlighting) (promql). Does not touch `offlinedocs/`. Linear: [DOCS-476](https://linear.app/codercom/issue/DOCS-476/normalize-docs-code-fence-languages-de-risk-shikifumadocs) <details> <summary>How the fence tags were verified</summary> Each tag was tested against a real `shiki@latest` highlighter instance (`codeToHtml`/`codeToTokens`) and cross-checked against GitHub's `@wooorm/starry-night` grammar sources (the renderer that actually displays these `.md` files today, in repo browsing and PR diffs), since that's what determines whether brevity is safe before Shiki adoption: ```text FAIL env -- Language `env` is not included in this bundle. FAIL Dockerfile -- Language `Dockerfile` is not included in this bundle. FAIL promql -- Language `promql` is not included in this bundle. FAIL caddyfile -- Language `caddyfile` is not included in this bundle. FAIL pwsh -- Language `pwsh` is not included in this bundle. FAIL output -- Language `output` is not included in this bundle. ``` `hcl` doesn't error in Shiki, since it's a real grammar, but that's exactly the trap: it was silently rendering every fence with the generic HCL grammar instead of the Terraform-specific one. Every `hcl`-tagged fence in `docs/**` was manually checked against `origin/main` and is genuinely Terraform content. For `ts`/`tsx`, tokenizing the actual doc content confirmed identical output under both grammars; a synthetic test with the legacy angle-bracket cast syntax confirmed `tsx` degrades on that specific construct, which the style guide now calls out. The first normalization pass only matched fence tags at column 0 (`^```tag$`), missing tags indented inside numbered/bulleted lists. A follow-up pass caught the remaining occurrences at any indentation level. </details> --- *This PR description and the underlying changes were prepared with Coder Agents assistance.*
8.8 KiB
Visual Studio Code
You can develop in your Coder workspace remotely with VS Code. We support connecting with the desktop client and VS Code in the browser with code-server. Learn more about how VS Code Web and code-server compare in the code-server doc.
VS Code Desktop
VS Code desktop is a default app for workspaces.
Click VS Code Desktop in the dashboard to one-click enter a workspace. This
automatically installs the Coder Remote
extension, authenticates with Coder, and connects to the workspace.
Note
The
VS Code Desktopbutton can be hidden by enabling Browser-only connections.
Manual Installation
You can install our extension manually in VS Code using the command palette. Launch VS Code Quick Open (Ctrl+P), paste the following command, and press enter.
ext install coder.coder-remote
Alternatively, manually install the VSIX from the latest release.
Local telemetry
The Coder Remote extension records local telemetry to help diagnose extension and workspace connection issues. Telemetry is stored on your machine. It is not sent to Coder unless you export it or include it in a support bundle and share that file.
Local telemetry is controlled by the VS Code setting coder.telemetry.level:
| Value | Behavior |
|---|---|
off |
Disable extension telemetry collection. |
local |
Record telemetry events on this machine. This is the default. |
Stored data
Telemetry can include diagnostic details such as extension version, VS Code version, operating system, machine and session identifiers, deployment URL, workspace and agent names, command outcomes, connection state, request routes, timing, and error details. It does not intentionally collect source code, terminal contents, tokens, or credentials.
Tracked activity
The exact events vary by extension version. For a comprehensive list of current events, properties, and attributes, see the extension event reference. The following categories summarize the diagnostic signals the extension may record:
| Area | Examples |
|---|---|
| Extension lifecycle | Activation, deployment initialization, and configuration loading. |
| Authentication and credentials | Sign-in state, token refresh, logout, credential storage, and deployment recovery. |
| Commands and diagnostics | Command outcomes, telemetry exports, support bundle creation, ping, and speed tests. |
| Workspace workflows | Workspace selection, open attempts, dev container handoff, start, and update prompts. |
| CLI and remote setup | CLI binary resolution, download, verification, configuration, and setup through SSH handoff. |
| Connection health | Workspace and agent state transitions, reconnects, SSH process health, and network samples. |
| HTTP diagnostics | Normalized routes, status classes, and latency rollups. |
Storage and retention
The extension stores telemetry as JSON Lines files in its VS Code global storage
under a telemetry directory. Files rotate at 5 MiB, are kept for up to 30 days,
and are capped at 100 MiB total by default.
You can tune local retention with the advanced coder.telemetry.local setting.
Most users should keep the default values.
Diagnostics and support bundles
The extension includes commands for collecting diagnostics from VS Code:
- Coder: Export Telemetry exports only local telemetry. Choose a date range and JSON or OTLP JSON zip format, then review the file before sharing it.
- Coder: Create Support Bundle runs
coder support bundleand adds avscode-logs/directory with recent VS Code extension diagnostics, including extension logs, proxy and Remote-SSH logs, redacted VS Code settings, and local telemetry files when available. Thevscode-logs/directory is only added when the bundle is created from the VS Code Coder Remote extension; bundles created with the CLI alone do not include it. - Coder: View Logs opens the extension output logs in VS Code.
Support bundles can contain sensitive diagnostic data. Review the generated bundle before sharing it. Learn more about support bundles.
VS Code extensions
There are multiple ways to add extensions to VS Code Desktop:
- Using the public extensions marketplaces with Code Web (code-server)
- Adding extensions to custom images
- Installing extensions
using its
vsixfile at the command line - Installing extensions from a marketplace using the command line
Using the public extensions marketplaces
You can manually add an extension while you're working in the Code Web IDE. The extensions can be from Coder's public marketplace, Eclipse Open VSX's public marketplace, or the Eclipse Open VSX local marketplace.
Note
Microsoft does not allow any unofficial VS Code IDE to connect to the extension marketplace.
Adding extensions to custom images
You can add extensions to a custom image and install them either through Code Web or using the workspace's terminal.
-
Download the extension(s) from the Microsoft public marketplace.
-
Add the
vsixextension files to the same folder as your Dockerfile.~/images/base ➜ ls -l -rw-r--r-- 1 coder coder 0 Aug 1 19:23 Dockerfile -rw-r--r-- 1 coder coder 8925314 Aug 1 19:40 GitHub.copilot.vsix -
In the Dockerfile, add instructions to make a folder and to copy the
vsixfiles into the newly created folder.FROM codercom/enterprise-base:ubuntu # Run below commands as root user USER root # Download and install VS Code extensions into the container RUN mkdir -p /vsix ADD ./GitHub.copilot.vsix /vsix USER coder -
Build the custom image, and push it to your image registry.
-
Pass in the image and below command into your template
startup_script(be sure to update the filename below):Startup Script
resource "coder_agent" "main" { ... startup_script = "code-server --install-extension /vsix/GitHub.copilot.vsix" }Image Definition
resource "kubernetes_deployment" "main" { spec { template { spec { container { name = "dev" image = "registry.internal/image-name:tag" } } } } } -
Create a workspace using the template.
You will now have access to the extension in your workspace.
Installing extensions using its vsix file at the command line
Using the workspace's terminal or the terminal available inside code-server,
you can install an extension whose files you've downloaded from a marketplace:
/path/to/code-server --install-extension /vsix/GitHub.copilot.vsix
Installing from a marketplace at the command line
Using the workspace's terminal or the terminal available inside Code Web (code server), run the following to install an extension (be sure to update the snippets with the name of the extension you want to install):
SERVICE_URL=https://extensions.coder.com/api ITEM_URL=https://extensions.coder.com/item /path/to/code-server --install-extension GitHub.copilot
Alternatively, you can install an extension from Open VSX's public marketplace:
SERVICE_URL=https://open-vsx.org/vscode/gallery ITEM_URL=https://open-vsx.org/vscode/item /path/to/code-server --install-extension GitHub.copilot
Using VS Code Desktop
For your local VS Code to pickup extension files in your Coder workspace,
include this command in your startup_script, or run in manually in your
workspace terminal:
code --extensions-dir ~/.vscode-server/extensions --install-extension "$extension"


