Files
coder/docs/user-guides/shared-workspaces.md
T
Nick Vigilante c84aa564ba docs: normalize code-fence languages for Shiki compatibility (#27161)
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.*
2026-07-15 14:07:09 -04:00

5.4 KiB
Raw Blame History

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, with use permissions
  • coder sharing share <workspace> --user alice:admin,bob
    • Shares the workspace with two users - alice with admin permissions, and bob with use permissions
  • coder sharing share <workspace> --group contractor
    • Shares the workspace with contractor, which is a group of users

To remove sharing from a workspace:

  • coder sharing remove <workspace> --user alice
    • Workspace is no longer shared with the user alice.
  • coder sharing remove <workspace> --group contractor
    • Workspace is no longer shared with the group contractor.

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:true
  • coder list --search shared_with_user:me
  • coder list --search shared_with_user:<user>
  • coder list --search shared_with_group:<group>

UI

Sharing your Workspace

  1. Open a workspace that you own.

  2. Locate and click the 'Share' button.

Sharing a workspace

  1. Add the users or groups that you want to share the workspace with. For each one, select a role.

Sharing with a user or group

  • use allows for connection via SSH and apps, the ability to start and stop the workspace, view logs and stats, and update on start when required.
  • admin allows for all of the above, as well as the ability to rename the workspace, update at any time, and invite others with the use role.
  • 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.

Sharing with a user or group

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:

  1. Set a wildcard access URL on your deployment (e.g., CODER_WILDCARD_ACCESS_URL=*.coder.example.com).

  2. Set subdomain = true on 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.