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.*
5.4 KiB
Shared Workspaces
Multiple users can securely connect to a single Coder workspace for programming and debugging.
Features
Workspace sharing is available to all Coder users by default, but platform admins with a Premium subscription can choose to disable sharing within their organizations or for their entire deployment.
Owners of a workspace can grant access to other users or groups with scoped roles.
This is helpful in a number of scenarios, including:
- Developers can do ad-hoc debugging or pair programming.
- A workspace can be owned by a group of users for QA, on-call rotations, or shared staging.
- AI workflows where an agent prepares a workspace and a developer takes over to review or finalize the work (ex. with Coder Tasks.)
Getting Started
Workspaces can be shared through either the Coder CLI or UI.
Before you begin, ensure that you have a version of Coder with workspace sharing enabled and that your account has permission to share workspaces. This is true by default if you are an OSS user, but deployments with Premium licenses may be restricted by admins.
CLI
To share a workspace:
coder sharing share <workspace> --user alice- Shares the workspace with a single user,
alice, withusepermissions
- Shares the workspace with a single user,
coder sharing share <workspace> --user alice:admin,bob- Shares the workspace with two users -
alicewithadminpermissions, andbobwithusepermissions
- Shares the workspace with two users -
coder sharing share <workspace> --group contractor- Shares the workspace with
contractor, which is a group of users
- Shares the workspace with
To remove sharing from a workspace:
coder sharing remove <workspace> --user alice- Workspace is no longer shared with the user
alice.
- Workspace is no longer shared with the user
coder sharing remove <workspace> --group contractor- Workspace is no longer shared with the group
contractor.
- Workspace is no longer shared with the group
Important
The workspace must be restarted for the user or group removal to take effect.
To show who a workspace is shared with:
coder sharing status <workspace>
To list shared workspaces:
coder list --search shared:truecoder list --search shared_with_user:mecoder list --search shared_with_user:<user>coder list --search shared_with_group:<group>
UI
Sharing your Workspace
-
Open a workspace that you own.
-
Locate and click the 'Share' button.
- Add the users or groups that you want to share the workspace with. For each one, select a role.
useallows for connection via SSH and apps, the ability to start and stop the workspace, view logs and stats, and update on start when required.adminallows for all of the above, as well as the ability to rename the workspace, update at any time, and invite others with theuserole.- Neither role allows for the user to delete the workspace.
- After removing a user/group, a workspace restart is required for the removal to take effect.
Using a shared workspace
Once a workspace is shared, you can find the shared workspace by filtering for "Shared" in the Workspaces page.
Accessing workspace apps in shared workspaces
Sharing a workspace grants SSH and terminal access to other users. However, workspace apps like code-server may return a 404 page for non-owners depending on how the app is routed.
By default, workspace apps that don't set subdomain = true use path-based
routing (e.g., coder.example.com/@user/workspace/apps/code-server/).
Path-based apps share the same origin as the Coder dashboard, so Coder blocks
non-owners from accessing them to prevent
cross-site scripting risks.
This restriction applies even when the user has been granted access through
workspace sharing.
To allow other users to access workspace apps, configure subdomain-based access:
-
Set a wildcard access URL on your deployment (e.g.,
CODER_WILDCARD_ACCESS_URL=*.coder.example.com). -
Set
subdomain = trueon the workspace app. For example, if you use the code-server module:module "code-server" { source = "registry.coder.com/coder/code-server/coder" agent_id = coder_agent.main.id subdomain = true # ... }
Subdomain-based apps run in an isolated browser security context, so Coder allows other users to access them without additional configuration.
Policies
There are several sharing policy levels that can be selected on a per-organization basis.
- Everyone – Anybody can share their workspace with any individual or group in the same organization.
- Service Accounts Only – Only workspaces owned by service accounts can be shared with any individual or group in the same organization.
- Disabled – Workspaces within the organization cannot be shared.
The Disabled policy can also be applied to the entire deployment by setting the CODER_DISABLE_WORKSPACE_SHARING environment variable, or by using the corresponding command argument or config value.


