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.7 KiB
Improving Agent Resiliency
Coder's agent can automatically lower the scheduling priority and raise the OOM (out-of-memory) kill score of user processes so the agent itself stays alive under resource pressure.
Prerequisites
-
Linux — The feature is ignored on other operating systems.
-
CAP_SYS_NICE— Required if the agent needs to lower the nice value below its current value. In Kubernetes, add it to the container's security context:container { security_context { capabilities { add = ["CAP_SYS_NICE"] } } }
Environment variables
Configure the feature with environment variables in the
environment that launches the agent binary. These must be set
on the workspace container or host, not in the coder_agent
resource's env block — the agent reads them from its own
process environment at startup.
| Variable | Required | Default | Description |
|---|---|---|---|
CODER_PROC_PRIO_MGMT |
Yes | — | Set to enable the feature. The agent checks whether the variable is present, not its value — even an empty string enables it. Use 1 by convention. To disable, unset the variable entirely. |
CODER_PROC_OOM_SCORE |
No | Computed from agent's score | Explicit oom_score_adj value for child processes. Range: -1000 to 1000. |
CODER_PROC_NICE_SCORE |
No | Agent nice + 5 (capped at 19) | Explicit nice value for child processes. Range: -20 to 19 (higher = lower priority). |
OOM score defaults
If you do not set CODER_PROC_OOM_SCORE, the agent computes a
value based on its own oom_score_adj:
Agent's oom_score_adj |
Child score | Rationale |
|---|---|---|
| Negative (< 0) | 0 |
Children are treated as normal processes. |
| >= 998 | 1000 |
Children get the maximum score (killed first). |
| Any other value | 998 |
Children get a near-maximum score. |
The goal is for the kernel's OOM killer to target child processes before the agent, keeping remote connectivity alive even when a workspace runs out of memory.
Nice score defaults
If you do not set CODER_PROC_NICE_SCORE, the agent sets
children to its own nice value plus 5, capped at 19. This
gives the agent more CPU scheduling priority than user
workloads.
Example
The following Kubernetes template snippet enables process priority management on the workspace container:
resource "kubernetes_deployment" "workspace" {
# ... other configuration
spec {
template {
spec {
container {
name = "dev"
image = "codercom/enterprise-base:ubuntu"
env {
name = "CODER_AGENT_TOKEN"
value = coder_agent.main.token
}
env {
name = "CODER_PROC_PRIO_MGMT"
value = "1"
}
env {
name = "CODER_PROC_OOM_SCORE"
value = "10"
}
env {
name = "CODER_PROC_NICE_SCORE"
value = "1"
}
security_context {
capabilities {
add = ["CAP_SYS_NICE"]
}
}
}
}
}
}
}
CODER_PROC_OOM_SCORE=10gives child processes a slightly elevated OOM score while keeping them well below the maximum.CODER_PROC_NICE_SCORE=1gives children a mildly lower CPU priority than the agent.CAP_SYS_NICEallows the agent to set nice values.
Troubleshooting
OOM score adjustment fails
If you see failed to adjust oom score in stderr but the
process still starts, the agent likely lacks permission to
write to /proc/self/oom_score_adj. Ensure the process is
dumpable — this is handled automatically by the agent, but
can fail if the container runtime restricts prctl calls.
Nice value is not applied
If you see failed to adjust niceness in stderr, nice values
can only be increased (lowered in priority) without
CAP_SYS_NICE. If your template sets a CODER_PROC_NICE_SCORE
lower than the agent's current nice value, add the capability
to the container's security context.
Environment variables leak to nested Coder agents
The agent strips all CODER_PROC_* variables from child
environments automatically. This prevents interference in
"Coder on Coder" development scenarios where a workspace
runs another Coder agent.
Verifying the feature is enabled
The agent logs whether process priority management is active at startup. Look for these lines in the agent log:
"process priority management enabled"
"process priority management not enabled (linux-only)"
The log entry includes the CODER_PROC_PRIO_MGMT value and
the operating system. Check the agent log file at
<log-dir>/coder-agent.log or stderr output.
Feature has no effect on macOS or Windows
Process priority management is Linux-only. Setting
CODER_PROC_PRIO_MGMT on other operating systems is safe
but has no effect.