docs, site: rename coder_agent references to coder_workspace_daemon

Rename coder_agent terraform resource references and associated prose
to coder_workspace_daemon across docs and frontend UI strings. This
disambiguates the terraform resource from AI agent references.

Docs (82 files):
- Terraform resource declarations and attribute references
- Terraform registry URLs
- Prose: 'Coder agent', 'workspace agent', 'the agent' → 'workspace daemon'
- Devcontainer sub-agents → sub-daemons

Frontend (9 files):
- Workspace alert/error banners
- Tooltips, toasts, aria-labels
- Connection log help text

Preserved unchanged:
- CODER_AGENT_* environment variables
- CLI flags, API fields, metric names
- Generated types and RBAC resources
- AI agent UI (AgentsPage, TaskPrompt, etc.)
- Variable names, component names, query keys

docs/about/contributing/backend.md

@@ -49,7 +49,7 @@ Coder's backend is built using a collection of robust, modern Go libraries and i
 
 The Coder backend is organized into multiple packages and directories, each with a specific purpose. Here's a high-level overview of the most important ones:
 
-* [agent](https://github.com/coder/coder/tree/main/agent): core logic of a workspace agent, supports DevContainers, remote SSH, startup/shutdown script execution. Protobuf definitions for DRPC communication with `coderd` are kept in [proto](https://github.com/coder/coder/tree/main/agent/proto).
+* [agent](https://github.com/coder/coder/tree/main/agent): core logic of a workspace daemon, supports DevContainers, remote SSH, startup/shutdown script execution. Protobuf definitions for DRPC communication with `coderd` are kept in [proto](https://github.com/coder/coder/tree/main/agent/proto).
 * [cli](https://github.com/coder/coder/tree/main/cli): CLI interface for `coder` command built on [coder/serpent](https://github.com/coder/serpent). Input controls are defined in [cliui](https://github.com/coder/coder/tree/docs-backend-contrib-guide/cli/cliui), and [testdata](https://github.com/coder/coder/tree/docs-backend-contrib-guide/cli/testdata) contains golden files for common CLI calls
 * [cmd](https://github.com/coder/coder/tree/main/cmd): entry points for CLI and services, including `coderd`
 * [coderd](https://github.com/coder/coder/tree/main/coderd): the main API server implementation with [chi](https://github.com/go-chi/chi) endpoints
@@ -83,7 +83,7 @@ The Coder backend is organized into multiple packages and directories, each with
 * [provisionerd](https://github.com/coder/coder/tree/main/provisionerd): core logic of provisioner runner to interact provisionerd server, depending on a job acquired it calls template import, dry run or a workspace build
 * [pty](https://github.com/coder/coder/tree/main/pty): terminal emulation for agent shell
 * [support](https://github.com/coder/coder/tree/main/support): compile a support bundle with diagnostics
-* [tailnet](https://github.com/coder/coder/tree/main/tailnet): core logic of Tailnet controller to maintain DERP maps, coordinate connections with agents and peers
+* [tailnet](https://github.com/coder/coder/tree/main/tailnet): core logic of Tailnet controller to maintain DERP maps, coordinate connections with workspace daemons and peers
 * [vpn](https://github.com/coder/coder/tree/main/vpn): Coder Desktop (VPN) and tunneling components
 
 ## Testing
@@ -136,7 +136,7 @@ Try to find answers to these questions before jumping into implementation work
 
 1. When you create a template, what does that do exactly?
 2. When you create a workspace, what exactly happens?
-3. How does the agent get the required information to run?
+3. How does the workspace daemon get the required information to run?
 4. How are provisioner jobs run?
 
 ## Recipes

docs/about/contributing/modules.md

@@ -115,7 +115,7 @@ terraform {
 
 # Input variables
 variable "agent_id" {
-  description = "The ID of a Coder agent"
+  description = "The ID of a Coder workspace daemon"
   type        = string
 }
 
@@ -217,7 +217,7 @@ module "git_clone" {
   source   = "registry.coder.com/[your-username]/git-clone/coder"
   version  = "~> 1.0"
   
-  agent_id = coder_agent.main.id
+  agent_id = coder_workspace_daemon.main.id
   url      = "https://github.com/coder/coder.git"
   base_dir = "/home/coder/projects"
 }

docs/about/contributing/templates.md

@@ -7,7 +7,7 @@ Learn how to create and contribute complete Coder workspace templates to the Cod
 Coder templates are complete Terraform configurations that define entire workspace environments. Unlike modules (which are reusable components), templates provide full infrastructure definitions that include:
 
 - Infrastructure setup (containers, VMs, cloud resources)
-- Coder agent configuration
+- Workspace daemon configuration
 - Development tools and IDE integrations
 - Networking and security settings
 - Complete startup automation
@@ -116,8 +116,8 @@ terraform {
 data "coder_workspace" "me" {}
 data "coder_workspace_owner" "me" {}
 
-# Coder agent
-resource "coder_agent" "main" {
+# Coder workspace daemon
+resource "coder_workspace_daemon" "main" {
   arch                   = "amd64"
   os                     = "linux"
   startup_script_timeout = 180
@@ -136,13 +136,13 @@ resource "coder_agent" "main" {
 module "code-server" {
   source   = "registry.coder.com/coder/code-server/coder"
   version  = "~> 1.0"
-  agent_id = coder_agent.main.id
+  agent_id = coder_workspace_daemon.main.id
 }
 
 module "git-clone" {
   source   = "registry.coder.com/coder/git-clone/coder"
   version  = "~> 1.0"
-  agent_id = coder_agent.main.id
+  agent_id = coder_workspace_daemon.main.id
   url      = "https://github.com/example/repo.git"
 }
 
@@ -156,8 +156,8 @@ resource "docker_container" "workspace" {
   image = docker_image.main.name
   name  = "coder-${data.coder_workspace_owner.me.name}-${data.coder_workspace.me.name}"
   
-  command = ["sh", "-c", coder_agent.main.init_script]
-  env     = ["CODER_AGENT_TOKEN=${coder_agent.main.token}"]
+  command = ["sh", "-c", coder_workspace_daemon.main.init_script]
+  env     = ["CODER_AGENT_TOKEN=${coder_workspace_daemon.main.token}"]
   
   host {
     host = "host.docker.internal"
@@ -236,7 +236,7 @@ You can customize this template by:
 **Solution**: Ensure Docker is running and accessible
 
 **Issue**: VS Code not accessible
-**Solution**: Check agent logs and ensure code-server module is properly configured
+**Solution**: Check workspace daemon logs and ensure code-server module is properly configured
 ```
 
 ## Template best practices
@@ -265,7 +265,7 @@ module "code-server" {
   count    = data.coder_workspace.me.start_count
   source   = "registry.coder.com/coder/code-server/coder"
   version  = "1.3.0"
-  agent_id = coder_agent.example.id
+  agent_id = coder_workspace_daemon.example.id
 }
 
 # JetBrains IDEs
@@ -273,7 +273,7 @@ module "jetbrains" {
   count    = data.coder_workspace.me.start_count
   source   = "registry.coder.com/coder/jetbrains/coder"
   version  = "1.0.0"
-  agent_id = coder_agent.example.id
+  agent_id = coder_workspace_daemon.example.id
   folder   = "/home/coder/project"
 }
 
@@ -282,7 +282,7 @@ module "git-clone" {
   count    = data.coder_workspace.me.start_count
   source   = "registry.coder.com/coder/git-clone/coder"
   version  = "1.1.0"
-  agent_id = coder_agent.example.id
+  agent_id = coder_workspace_daemon.example.id
   url      = "https://github.com/coder/coder"
   base_dir = "~/projects/coder"
 }
@@ -292,7 +292,7 @@ module "filebrowser" {
   count    = data.coder_workspace.me.start_count
   source   = "registry.coder.com/coder/filebrowser/coder"
   version  = "1.1.1"
-  agent_id = coder_agent.example.id
+  agent_id = coder_workspace_daemon.example.id
 }
 
 # Dotfiles management
@@ -300,7 +300,7 @@ module "dotfiles" {
   count    = data.coder_workspace.me.start_count
   source   = "registry.coder.com/coder/dotfiles/coder"
   version  = "1.2.0"
-  agent_id = coder_agent.example.id
+  agent_id = coder_workspace_daemon.example.id
 }
 ```
 
@@ -350,7 +350,7 @@ coder create test-workspace --template test-template
 Before submitting your template, verify:
 
 - [ ] Template provisions successfully
-- [ ] Agent connects properly
+- [ ] Workspace daemon connects properly
 - [ ] All registry modules work correctly
 - [ ] VS Code/IDEs are accessible
 - [ ] Networking functions properly
@@ -364,7 +364,7 @@ Before submitting your template, verify:
 **Bug fixes**:
 
 - Fix setup issues
-- Resolve agent connectivity problems
+- Resolve workspace daemon connectivity problems
 - Correct resource configurations
 
 **Feature additions**:
@@ -436,8 +436,8 @@ resource "docker_container" "workspace" {
   image = "ubuntu:24.04"
   name  = "coder-${data.coder_workspace_owner.me.name}-${data.coder_workspace.me.name}"
   
-  command = ["sh", "-c", coder_agent.main.init_script]
-  env     = ["CODER_AGENT_TOKEN=${coder_agent.main.token}"]
+  command = ["sh", "-c", coder_workspace_daemon.main.init_script]
+  env     = ["CODER_AGENT_TOKEN=${coder_workspace_daemon.main.token}"]
 }
 ```
 
@@ -450,7 +450,7 @@ resource "aws_instance" "workspace" {
   ami           = data.aws_ami.ubuntu.id
   instance_type = var.instance_type
   
-  user_data = coder_agent.main.init_script
+  user_data = coder_workspace_daemon.main.init_script
   
   tags = {
     Name = "coder-${data.coder_workspace_owner.me.name}-${data.coder_workspace.me.name}"
@@ -474,10 +474,10 @@ resource "kubernetes_pod" "workspace" {
       name  = "workspace"
       image = "ubuntu:24.04"
       
-      command = ["sh", "-c", coder_agent.main.init_script]
+      command = ["sh", "-c", coder_workspace_daemon.main.init_script]
       env {
         name  = "CODER_AGENT_TOKEN"
-        value = coder_agent.main.token
+        value = coder_workspace_daemon.main.token
       }
     }
   }
@@ -491,8 +491,8 @@ resource "kubernetes_pod" "workspace" {
 **Issue**: Template fails to create resources
 **Solution**: Check Terraform syntax and provider configuration
 
-**Issue**: Agent doesn't connect
-**Solution**: Verify agent token and network connectivity
+**Issue**: Workspace daemon doesn't connect
+**Solution**: Verify workspace daemon token and network connectivity
 
 ### Documentation
 

docs/admin/external-auth/index.md

@@ -339,7 +339,7 @@ CODER_EXTERNAL_AUTH_0_SCOPES="repo:read repo:write write:gpg_key"
 Below is an example configuration with multiple providers:
 
 > [!IMPORTANT]
-> To support regex matching for paths like `github\.com/org`, add the following `git config` line to the [Coder agent startup script](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent#startup_script):
+> To support regex matching for paths like `github\.com/org`, add the following `git config` line to the [workspace daemon startup script](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent#startup_script):
 >
 > ```shell
 > git config --global credential.useHttpPath true

docs/admin/index.md

@@ -37,7 +37,7 @@ For any information not strictly contained in these sections, check out our
 
 ### Startup scripts
 
-- Agent startup scripts apply to all users of a template. This is an
+- Workspace daemon startup scripts apply to all users of a template. This is an
   intentionally flexible area that template authors have at their disposal to
   manage the "last mile" of workspace creation.
 - Managed by: Coder template administrators.

docs/admin/infrastructure/architecture.md

@@ -34,7 +34,7 @@ It offers:
 - HTTP API
 - Dev URLs (HTTP reverse proxy to workspaces)
 - Workspace Web Applications (e.g for easy access to `code-server`)
-- Agent registration
+- Workspace daemon registration
 
 ### provisionerd
 
@@ -51,15 +51,15 @@ At the highest level, a workspace is a set of cloud resources. These resources
 can be VMs, Kubernetes clusters, storage buckets, or whatever else Terraform
 lets you dream up.
 
-The resources that run the agent are described as _computational resources_,
+The resources that run the workspace daemon are described as _computational resources_,
 while those that don't are called _peripheral resources_.
 
 Each resource may also be _persistent_ or _ephemeral_ depending on whether
 they're destroyed on workspace stop.
 
-### Agents
+### Workspace daemons
 
-An agent is the Coder service that runs within a user's remote workspace. It
+A workspace daemon is the Coder service that runs within a user's remote workspace. It
 provides a consistent interface for coderd and clients to communicate with
 workspaces regardless of operating system, architecture, or cloud.
 
@@ -71,7 +71,7 @@ It offers the following services along with much more:
 - `startup_script` automation
 
 Templates are responsible for
-[creating and running agents](../templates/extending-templates/index.md#workspace-agents)
+[creating and running workspace daemons](../templates/extending-templates/index.md#workspace-agents)
 within workspaces.
 
 ## Service Bundling

docs/admin/infrastructure/scale-testing.md

@@ -21,7 +21,7 @@ Our scale tests include the following stages:
 
 1. Prepare environment: create expected users and provision workspaces.
 
-1. SSH connections: establish user connections with agents, verifying their
+1. SSH connections: establish user connections with workspace daemons, verifying their
    ability to echo back received content.
 
 1. Web Terminal: verify the PTY connection used for communication with Web
@@ -70,7 +70,7 @@ workflows,
 ## Traffic Projections
 
 In our scale tests, we simulate activity from 2000 users, 2000 workspaces, and
-2000 agents, with two items of workspace agent metadata being sent every 10
+2000 workspace daemons, with two items of workspace daemon metadata being sent every 10
 seconds. Here are the resulting metrics:
 
 Coder:
@@ -79,7 +79,7 @@ Coder:
   running concurrently.
 - Median API request rate: 350 RPS during dashboard tests, 250 RPS during Web
   Terminal and workspace apps tests.
-- 2000 agent API connections with latency: p90 at 60 ms, p95 at 220 ms.
+- 2000 workspace daemon API connections with latency: p90 at 60 ms, p95 at 220 ms.
 - on average 2400 Web Socket connections during dashboard tests.
 
 Provisionerd:
@@ -89,7 +89,7 @@ Provisionerd:
 Database:
 
 - Median CPU utilization is 80%, with a significant portion dedicated to writing
-  workspace agent metadata.
+  workspace daemon metadata.
 - Memory utilization averages at 40%.
 - `write_ops_count` between 6.7 and 8.4 operations per second.
 
@@ -120,10 +120,10 @@ on the workload size to ensure deployment stability.
 #### CPU and memory usage
 
 Enabling
-[agent stats collection](../../reference/cli/server.md#--prometheus-collect-agent-stats)
+[workspace daemon stats collection](../../reference/cli/server.md#--prometheus-collect-agent-stats)
 (optional) may increase memory consumption.
 
-Enabling direct connections between users and workspace agents (apps or SSH
+Enabling direct connections between users and workspace daemons (apps or SSH
 traffic) can help prevent an increase in CPU usage. It is recommended to keep
 [this option enabled](../../reference/cli/index.md#--disable-direct-connections)
 unless there are compelling reasons to disable it.
@@ -149,7 +149,7 @@ When determining scaling requirements, consider the following factors:
 For a reliable Coder deployment dealing with medium to high loads, it's
 important that API calls for workspace/template queries and workspace build
 operations respond within 300 ms. However, API template insights calls, which
-involve browsing workspace agent stats and user activity data, may require more
+involve browsing workspace daemon stats and user activity data, may require more
 time. Moreover, Coder API exposes WebSocket long-lived connections for Web
 Terminal (bidirectional), and Workspace events/logs (unidirectional).
 
@@ -213,7 +213,7 @@ for workspace users, administrators must be aware of a few assumptions.
     development does not require high CPU capacity at all times, but will spike
     during builds or testing.
   - Evaluate minimal limits for single workspace. Include in the calculation
-    requirements for Coder agent running in an idle workspace - 0.1 vCPU and 256
+    requirements for the workspace daemon running in an idle workspace - 0.1 vCPU and 256
     MB. For instance, developers can choose between 0.5-8 vCPUs, and 1-16 GB
     memory.
 
@@ -223,7 +223,7 @@ When determining scaling requirements, consider the following factors:
 
 - `1 vCPU x 2 GB memory x 1 workspace`: A formula to determine resource
   allocation based on the minimal requirements for an idle workspace with a
-  running Coder agent and occasional CPU and memory bursts for building
+  running workspace daemon and occasional CPU and memory bursts for building
   projects.
 
 #### Node Autoscaling

docs/admin/infrastructure/scale-utility.md

@@ -150,7 +150,7 @@ apps.
 The _scaletest-runner_ offers the following configuration options:
 
 - Workspace size selection: minimal/small/medium/large (_default_: minimal,
-  which contains just enough resources for a Coder agent to run without
+  which contains just enough resources for a workspace daemon to run without
   additional workloads)
 - Number of workspaces
 - Wait duration between scenarios or staggered approach
@@ -186,17 +186,17 @@ There are a few cluster options available:
 |----------------|------|--------|-------------------|-------------------------------------------------------|
 | minimal        | 1    | 2 Gi   | None              |                                                       |
 | small          | 1    | 1 Gi   | None              |                                                       |
-| medium         | 2    | 2 Gi   | None              | Medium-sized cluster offers the greedy agent variant. |
+| medium         | 2    | 2 Gi   | None              | Medium-sized cluster offers the greedy workspace daemon variant. |
 | large          | 4    | 4 Gi   | None              |                                                       |
 
 Note: Review the selected cluster template and edit the node affinity to match
 your setup.
 
-#### Greedy agent
+#### Greedy workspace daemon
 
-The greedy agent variant is a template modification that makes the Coder agent
+The greedy workspace daemon variant is a template modification that makes the workspace daemon
 transmit large metadata (size: 4K) while reporting stats. The transmission of
-large chunks puts extra overhead on coderd instances and agents when handling
+large chunks puts extra overhead on coderd instances and workspace daemons when handling
 and storing the data.
 
 Use this template variant to verify limits of the cluster performance.

docs/admin/infrastructure/validated-architectures/10k-users.md

@@ -80,7 +80,7 @@ If you choose to deploy workspaces in multiple geographic regions, provision
 
 ### Workspaces
 
-The following resource requirements are for the Coder Workspace Agent, which runs alongside your end users work, and as
+The following resource requirements are for the workspace daemon, which runs alongside your end users work, and as
 such should be interpreted as the _bare minimum_ requirements for a Coder workspace. Size your workspaces to fit the use
 case your users will be undertaking. If in doubt, chose sizes based on the development environments your users are
 migrating from onto Coder.

docs/admin/infrastructure/validated-architectures/1k-users.md

@@ -63,7 +63,7 @@ architectural tier](./2k-users.md).
 
 ### Workspaces
 
-The following resource requirements are for the Coder Workspace Agent, which runs alongside your end users work, and as
+The following resource requirements are for the workspace daemon, which runs alongside your end users work, and as
 such should be interpreted as the _bare minimum_ requirements for a Coder workspace. Size your workspaces to fit the use
 case your users will be undertaking. If in doubt, chose sizes based on the development environments your users are
 migrating from onto Coder.

docs/admin/infrastructure/validated-architectures/2k-users.md

@@ -83,7 +83,7 @@ If you choose to deploy workspaces in multiple geographic regions, provision
 
 ### Workspaces
 
-The following resource requirements are for the Coder Workspace Agent, which runs alongside your end users work, and as
+The following resource requirements are for the workspace daemon, which runs alongside your end users work, and as
 such should be interpreted as the _bare minimum_ requirements for a Coder workspace. Size your workspaces to fit the use
 case your users will be undertaking. If in doubt, chose sizes based on the development environments your users are
 migrating from onto Coder.

docs/admin/infrastructure/validated-architectures/3k-users.md

@@ -81,7 +81,7 @@ If you choose to deploy workspaces in multiple geographic regions, provision
 
 ### Workspaces
 
-The following resource requirements are for the Coder Workspace Agent, which runs alongside your end users work, and as
+The following resource requirements are for the workspace daemon, which runs alongside your end users work, and as
 such should be interpreted as the _bare minimum_ requirements for a Coder workspace. Size your workspaces to fit the use
 case your users will be undertaking. If in doubt, chose sizes based on the development environments your users are
 migrating from onto Coder.

docs/admin/integrations/devcontainers/integration.md

@@ -28,7 +28,7 @@ This is the recommended approach for most use cases.
 ### Project Discovery
 
 Alternatively, enable automatic discovery of Dev Containers in Git repositories.
-The agent scans for `devcontainer.json` files and surfaces them in the Coder UI.
+The workspace daemon scans for `devcontainer.json` files and surfaces them in the Coder UI.
 See [Environment Variables](#environment-variables) for configuration options.
 
 This approach is useful when developers frequently switch between repositories
@@ -44,7 +44,7 @@ to ensure the `@devcontainers/cli` is installed in your workspace:
 module "devcontainers-cli" {
   count    = data.coder_workspace.me.start_count
   source   = "registry.coder.com/coder/devcontainers-cli/coder"
-  agent_id = coder_agent.dev.id
+  agent_id = coder_workspace_daemon.dev.id
 }
 ```
 
@@ -60,7 +60,7 @@ ready when you access the workspace:
 ```terraform
 resource "coder_devcontainer" "my-repository" {
   count            = data.coder_workspace.me.start_count
-  agent_id         = coder_agent.dev.id
+  agent_id         = coder_workspace_daemon.dev.id
   workspace_folder = "/home/coder/my-repository"
 }
 ```
@@ -71,7 +71,7 @@ a `devcontainer.json` file. Consider using the
 your repository is cloned and ready for automatic startup.
 
 For multi-repo workspaces, define multiple `coder_devcontainer` resources, each
-pointing to a different repository. Each one runs as a separate sub-agent with
+pointing to a different repository. Each one runs as a separate sub-daemon with
 its own terminal and apps in the dashboard.
 
 ## Enable Dev Containers Integration
@@ -110,7 +110,7 @@ the feature.
 
 **Default: `true`** • **Added in: v2.24.0**
 
-Enables the Dev Containers integration in the Coder agent.
+Enables the Dev Containers integration in the workspace daemon.
 
 The Dev Containers feature is enabled by default. You can explicitly disable it
 by setting this to `false`.
@@ -121,12 +121,12 @@ by setting this to `false`.
 
 Enables automatic discovery of Dev Containers in Git repositories.
 
-When enabled, the agent scans the configured working directory (set via the
-`directory` attribute in `coder_agent`, typically the user's home directory) for
+When enabled, the workspace daemon scans the configured working directory (set via the
+`directory` attribute in `coder_workspace_daemon`, typically the user's home directory) for
 Git repositories. If the directory itself is a Git repository, it searches that
 project. Otherwise, it searches immediate subdirectories for Git repositories.
 
-For each repository found, the agent looks for `devcontainer.json` files in the
+For each repository found, the workspace daemon looks for `devcontainer.json` files in the
 [standard locations](../../../user-guides/devcontainers/index.md#add-a-devcontainerjson)
 and surfaces discovered Dev Containers in the Coder UI. Discovery respects
 `.gitignore` patterns.
@@ -156,7 +156,7 @@ as the `agent_id`:
 ```terraform
 resource "coder_devcontainer" "my-repository" {
   count            = data.coder_workspace.me.start_count
-  agent_id         = coder_agent.dev.id
+  agent_id         = coder_workspace_daemon.dev.id
   workspace_folder = "/home/coder/my-repository"
 }
 
@@ -187,11 +187,11 @@ that depend on these resources inside dev containers, by passing the
 
 When a `coder_devcontainer` has any `coder_app`, `coder_script`, or `coder_env`
 resource attached, it becomes a **terraform-managed** dev container. This
-changes how Coder handles the sub-agent:
+changes how Coder handles the sub-daemon:
 
-- The sub-agent is pre-defined during Terraform provisioning rather than created
+- The sub-daemon is pre-defined during Terraform provisioning rather than created
   dynamically.
-- On dev container configuration changes, Coder updates the sub-agent in-place
+- On dev container configuration changes, Coder updates the sub-daemon in-place
   instead of deleting and recreating it.
 
 ### Interaction with devcontainer.json customizations
@@ -215,7 +215,7 @@ block in their `devcontainer.json` file. Available options include:
 - `ignore` — Hide a dev container from Coder completely
 - `autoStart` — Control whether the container starts automatically (requires
   `CODER_AGENT_DEVCONTAINERS_DISCOVERY_AUTOSTART_ENABLE` to be enabled)
-- `name` — Set a custom agent name
+- `name` — Set a custom workspace daemon name
 - `displayApps` — Control which built-in apps appear
 - `apps` — Define custom applications
 
@@ -239,7 +239,7 @@ provider "coder" {}
 data "coder_workspace" "me" {}
 data "coder_workspace_owner" "me" {}
 
-resource "coder_agent" "dev" {
+resource "coder_workspace_daemon" "dev" {
   arch                    = "amd64"
   os                      = "linux"
   startup_script_behavior = "blocking"
@@ -251,19 +251,19 @@ resource "coder_agent" "dev" {
 module "devcontainers-cli" {
   count    = data.coder_workspace.me.start_count
   source   = "registry.coder.com/coder/devcontainers-cli/coder"
-  agent_id = coder_agent.dev.id
+  agent_id = coder_workspace_daemon.dev.id
 }
 
 resource "coder_devcontainer" "my-repository" {
   count            = data.coder_workspace.me.start_count
-  agent_id         = coder_agent.dev.id
+  agent_id         = coder_workspace_daemon.dev.id
   workspace_folder = "/home/coder/my-repository"
 }
 
 # Attaching resources to dev containers is optional. By attaching
 # this resource to the dev container, we are changing how the dev
 # container will be treated by Coder. This limits the ability to
-# customize the injected agent via the devcontainer.json file.
+# customize the injected workspace daemon via the devcontainer.json file.
 resource "coder_env" "env" {
   count    = data.coder_workspace.me.start_count
   agent_id = coder_devcontainer.my-repository[0].subagent_id

docs/admin/integrations/jfrog-artifactory.md

@@ -75,7 +75,7 @@ To set this up, follow these steps:
      count          = data.coder_workspace.me.start_count
      source         = "registry.coder.com/modules/jfrog-oauth/coder"
      version        = "1.0.19"
-     agent_id       = coder_agent.example.id
+     agent_id       = coder_workspace_daemon.example.id
      jfrog_url      = "https://example.jfrog.io"
      username_field = "username" # If you are using GitHub to login to both Coder and Artifactory, use username_field = "username"
 
@@ -111,7 +111,7 @@ To set this up, follow these steps:
    module "jfrog" {
      source                   = "registry.coder.com/modules/jfrog-token/coder"
      version                  = "1.0.30"
-     agent_id                 = coder_agent.example.id
+     agent_id                 = coder_workspace_daemon.example.id
      jfrog_url                = "https://XXXX.jfrog.io"
      artifactory_access_token = var.artifactory_access_token
      package_managers = {

docs/admin/integrations/kubernetes-logs.md

@@ -49,7 +49,7 @@ and event data from the API server.
 
 coder-logstream-kube listens for pod creation events with containers that have
 the CODER_AGENT_TOKEN environment variable set. All pod events are streamed as
-logs to the Coder API using the agent token for authentication. For more
+logs to the Coder API using the workspace daemon token for authentication. For more
 details, see the
 [coder-logstream-kube](https://github.com/coder/coder-logstream-kube)
 repository.

docs/admin/integrations/prometheus.md

@@ -100,7 +100,7 @@ spec:
 You must first enable `coderd_agentstats_*` with the flag
 `--prometheus-collect-agent-stats`, or the environment variable
 `CODER_PROMETHEUS_COLLECT_AGENT_STATS` before they can be retrieved from the
-deployment. They will always be available from the agent.
+deployment. They will always be available from the workspace daemon.
 
 <!-- Code generated by 'make docs/admin/integrations/prometheus.md'. DO NOT EDIT -->
 

docs/admin/integrations/vault.md

@@ -27,7 +27,7 @@ To use this module, add the following code to your Terraform configuration.
 module "vault" {
   source               = "registry.coder.com/modules/vault-github/coder"
   version              = "1.0.7"
-  agent_id             = coder_agent.example.id
+  agent_id             = coder_workspace_daemon.example.id
   vault_addr           = "https://vault.example.com"
   coder_github_auth_id = "my-github-auth-id"
 }

docs/admin/monitoring/connection-logs.md

@@ -5,7 +5,7 @@
 > [Premium license](https://coder.com/pricing#compare-plans).
 > For more details, [contact your account team](https://coder.com/contact).
 
-The **Connection Log** page in the dashboard allows Auditors to monitor workspace agent connections.
+The **Connection Log** page in the dashboard allows Auditors to monitor workspace daemon connections.
 
 ## Workspace App Connections
 
@@ -21,7 +21,7 @@ performed via the dashboard.
 ## SSH and IDE Sessions
 
 The connection log aims to capture a record of all workspace SSH and IDE sessions.
-These events are reported by workspace agents, and their receipt by the server
+These events are reported by workspace daemons, and their receipt by the server
 is not guaranteed.
 
 ## How to Filter Connection Logs

docs/admin/monitoring/health-check.md

@@ -126,11 +126,11 @@ configured threshold to a higher value (this will not address the root cause).
 
 ## DERP
 
-Coder workspace agents may use
+Coder workspace daemons may use
 [DERP (Designated Encrypted Relay for Packets)](https://tailscale.com/blog/how-tailscale-works/#encrypted-tcp-relays-derp)
 to communicate with Coder. This requires connectivity to a number of configured
 [DERP servers](../../reference/cli/server.md#--derp-config-path) which are used
-to relay traffic between Coder and workspace agents. Coder periodically queries
+to relay traffic between Coder and workspace daemons. Coder periodically queries
 the health of its configured DERP servers and may return one or more of the
 following:
 
@@ -205,7 +205,7 @@ for long-lived connections:
 
 - Between users interacting with Coder's Web UI (for example, the built-in
   terminal, or VSCode Web),
-- Between workspace agents and `coderd`,
+- Between workspace daemons and `coderd`,
 - Between Coder [workspace proxies](../networking/workspace-proxies.md) and
   `coderd`.
 

docs/admin/monitoring/index.md

@@ -16,7 +16,7 @@ Learn how to install & read the docs on the
 
 ## Table of Contents
 
-- [Logs](./logs.md): Learn how to access to Coder server logs, agent logs, and
+- [Logs](./logs.md): Learn how to access to Coder server logs, workspace daemon logs, and
   even how to expose Kubernetes pod scheduling logs.
 - [Metrics](./metrics.md): Learn about the valuable metrics to measure on a
   Coder deployment, regardless of your monitoring stack.

docs/admin/monitoring/logs.md

@@ -31,12 +31,12 @@ operations behind workspaces and templates.
 
 ## Workspace Logs
 
-The [Coder agent](../infrastructure/architecture.md#agents) inside workspaces
+The [workspace daemon](../infrastructure/architecture.md#agents) inside workspaces
 provides useful logs around workspace-to-server and client-to-workspace
 connections. For Kubernetes workspaces, these are typically the pod logs as the
-agent runs via the container entrypoint.
+workspace daemon runs via the container entrypoint.
 
-Agent logs are also stored in the workspace filesystem by default:
+Workspace daemon logs are also stored in the workspace filesystem by default:
 
 - macOS/Linux: `/tmp/coder-agent.log`
 - Windows: Refer to the template code (e.g.

docs/admin/monitoring/notifications/index.md

@@ -96,7 +96,7 @@ You can modify the notification delivery behavior in your Coder deployment's
 You can monitor out of memory (OOM) and out of disk (OOD) errors and alert users
 when they overutilize memory and disk.
 
-This can help prevent agent disconnects due to OOM/OOD issues.
+This can help prevent workspace daemon disconnects due to OOM/OOD issues.
 
 To enable OOM/OOD notifications on a template, follow the steps in the
 [resource monitoring guide](../../templates/extending-templates/resource-monitoring.md).

docs/admin/networking/index.md

@@ -27,10 +27,10 @@ In order for clients and workspaces to be able to connect:
 >   workspace
 > - better than 0.5% random packet loss
 
-- All clients and agents must be able to establish a connection to the Coder
-  server (`CODER_ACCESS_URL`) over HTTP/HTTPS.
+- All clients and workspace daemons must be able to establish a connection to
+  the Coder server (`CODER_ACCESS_URL`) over HTTP/HTTPS.
 - Any reverse proxy or ingress between the Coder control plane and
-  clients/agents must support WebSockets.
+  clients/workspace daemons must support WebSockets.
 
 In order for clients to be able to establish direct connections:
 
@@ -46,26 +46,28 @@ In order for clients to be able to establish direct connections:
   and [JetBrains Plugin](https://plugins.jetbrains.com/plugin/19620-coder/), and
   [`ssh coder.<workspace>`](../../reference/cli/config-ssh.md) all utilize the
   CLI to establish a workspace connection.
-- Either the client or workspace agent are able to discover a reachable
-  `ip:port` of their counterpart. If the agent and client are able to
-  communicate with each other using their locally assigned IP addresses, then a
-  direct connection can be established immediately. Otherwise, the client and
-  agent will contact
+- Either the client or workspace daemon are able to discover a reachable
+  `ip:port` of their counterpart. If the workspace daemon and client are able
+  to communicate with each other using their locally assigned IP addresses,
+  then a direct connection can be established immediately. Otherwise, the
+  client and workspace daemon will contact
   [the configured STUN servers](../../reference/cli/server.md#--derp-server-stun-addresses)
   to try and determine which `ip:port` can be used to communicate with their
   counterpart. See [STUN and NAT](./stun.md) for more details on how this
   process works.
-- All outbound UDP traffic must be allowed for both the client and the agent on
+- All outbound UDP traffic must be allowed for both the client and the
+  workspace daemon on
   **all ports** to each others' respective networks.
-  - To establish a direct connection, both agent and client use STUN. This
-    involves sending UDP packets outbound on `udp/3478` to the configured
+  - To establish a direct connection, both workspace daemon and client use
+    STUN. This involves sending UDP packets outbound on `udp/3478` to the
+    configured
     [STUN server](../../reference/cli/server.md#--derp-server-stun-addresses).
-    If either the agent or the client are unable to send and receive UDP packets
-    to a STUN server, then direct connections will not be possible.
-  - Both agents and clients will then establish a
+    If either the workspace daemon or the client are unable to send and receive
+    UDP packets to a STUN server, then direct connections will not be possible.
+  - Both workspace daemons and clients will then establish a
     [WireGuard](https://www.wireguard.com/)️ tunnel and send UDP traffic on
-    ephemeral (high) ports. If a firewall between the client and the agent
-    blocks this UDP traffic, direct connections will not be possible.
+    ephemeral (high) ports. If a firewall between the client and the workspace
+    daemon blocks this UDP traffic, direct connections will not be possible.
 
 ## coder server
 
@@ -86,7 +88,7 @@ provider "coder" {
 }
 ```
 
-This is useful when debugging connectivity issues between the workspace agent
+This is useful when debugging connectivity issues between the workspace daemon
 and the Coder server.
 
 ## Web Apps
@@ -107,9 +109,10 @@ is no special geo-distribution configuration. To speed up direct connections,
 move the user and workspace closer together.
 
 Establishing a direct connection can be an involved process because both the
-client and workspace agent will likely be behind at least one level of NAT,
+client and workspace daemon will likely be behind at least one level of NAT,
 meaning that we need to use STUN to learn the IP address and port under which
-the client and agent can both contact each other. See [STUN and NAT](./stun.md)
+the client and workspace daemon can both contact each other. See
+[STUN and NAT](./stun.md)
 for more information on how this process works.
 
 If a direct connection is not available (e.g. client or server is behind NAT),
@@ -209,11 +212,11 @@ There are three main types of latency metrics for your Coder deployment:
 
 - Workspace connection latency:
 
-  The latency shown on the workspace dashboard measures the round-trip time between the workspace agent and its DERP relay server.
+  The latency shown on the workspace dashboard measures the round-trip time between the workspace daemon and its DERP relay server.
 
-  This metric is displayed in milliseconds on the workspace dashboard and specifically shows the agent-to-relay latency, not direct P2P connections.
+  This metric is displayed in milliseconds on the workspace dashboard and specifically shows the workspace-daemon-to-relay latency, not direct P2P connections.
 
-  To estimate the total end-to-end latency experienced by a user, add the dashboard-to-server latency to this agent-to-relay latency.
+  To estimate the total end-to-end latency experienced by a user, add the dashboard-to-server latency to this workspace-daemon-to-relay latency.
 
 - Database latency:
 

docs/admin/networking/port-forwarding.md

@@ -45,8 +45,8 @@ coder port-forward myworkspace --tcp 3000,9990-9999
 ```
 
 Forward the remote TCP port `3000` and all ports from `9990` to `9999` to their
-respective local ports to the `agent` in your Workspace (typically main or dev).
-This is needed when you have multiple agents in your workspace.
+respective local ports to the workspace daemon in your Workspace (typically main or dev).
+This is needed when you have multiple workspace daemons in your workspace.
 
 ```console
 coder port-forward myworkspace.agent --tcp 3000,9990-9999
@@ -65,7 +65,7 @@ proxy the deployment, and port forwarding will work.
 There is a
 [DNS limitation](https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1)
 where each segment of hostnames must not exceed 63 characters. If your app
-name, agent name, workspace name and username exceed 63 characters in the
+name, workspace daemon name, workspace name and username exceed 63 characters in the
 hostname, port forwarding via the dashboard will not work.
 
 ### From an coder_app resource
@@ -78,7 +78,7 @@ the `subdomain` and `share` settings:
 ```tf
 # node app
 resource "coder_app" "node-react-app" {
-  agent_id  = coder_agent.dev.id
+  agent_id  = coder_workspace_daemon.dev.id
   slug      = "node-react-app"
   icon      = "https://upload.wikimedia.org/wikipedia/commons/a/a7/React-icon.svg"
   url       = "http://localhost:3000"
@@ -105,7 +105,7 @@ accessible by users outside of the Coder deployment.
 Another way to port forward in the dashboard is to use the "Open Ports" button
 to specify an arbitrary port. Coder will also detect if apps inside the
 workspace are listening on ports, and list them below the port input (this is
-only supported on Windows and Linux workspace agents).
+only supported on Windows and Linux workspace daemons).
 
 ![Port forwarding in the UI](../../images/networking/listeningports.png)
 

docs/admin/networking/stun.md

@@ -15,8 +15,8 @@ In order for one application to connect to another across a network, the
 connecting application needs to know the IP address and port under which the
 target application is reachable. If both applications reside on the same
 network, then they can most likely connect directly to each other. In the
-context of a Coder workspace agent and client, this is generally not the case,
-as both agent and client will most likely be running in different _private_
+context of a Coder workspace daemon and client, this is generally not the case,
+as both workspace daemon and client will most likely be running in different _private_
 networks (e.g. `192.168.1.0/24`). In this case, at least one of the two will
 need to know an IP address and port under which they can reach their
 counterpart.
@@ -24,11 +24,12 @@ counterpart.
 This problem is often referred to as NAT traversal, and Coder uses a standard
 protocol named STUN to address this.
 
-Inside of that network, packets from the agent or client will show up as having
+Inside of that network, packets from the workspace daemon or client will show up as having
 source address `192.168.1.X:12345`. However, outside of this private network,
 the source address will show up differently (for example, `12.3.4.56:54321`). In
-order for the Coder client and agent to establish a direct connection with each
-other, one of them needs to know the `ip:port` pair under which their
+order for the Coder client and workspace daemon to establish a direct
+connection with each other, one of them needs to know the `ip:port` pair
+under which their
 counterpart can be reached. Once communication succeeds in one direction, we can
 inspect the source address of the received packet to determine the return
 address.
@@ -40,14 +41,14 @@ address.
 
 At a high level, STUN works like this:
 
-- **Discovery:** Both the client and agent will send UDP traffic to one or more
+- **Discovery:** Both the client and workspace daemon will send UDP traffic to one or more
   configured STUN servers. These STUN servers are generally located on the
   public internet, and respond with the public IP address and port from which
   the request came.
-- **Coordination:** The client and agent then exchange this information through
+- **Coordination:** The client and workspace daemon then exchange this information through
   the Coder server. They will then construct packets that should be able to
   successfully traverse their counterpart's NATs successfully.
-- **NAT Traversal:** The client and agent then send these crafted packets to
+- **NAT Traversal:** The client and workspace daemon then send these crafted packets to
   their counterpart's public addresses. If all goes well, the NATs on the other
   end should route these packets to the correct internal address.
 - **Connection:** Once the packets reach the other side, they send a response
@@ -55,33 +56,35 @@ At a high level, STUN works like this:
   these responses as belonging to an ongoing communication, and forward them
   accordingly.
 
-At this point, both the client and agent should be able to send traffic directly
+At this point, both the client and workspace daemon should be able to send traffic directly
 to each other.
 
 ## Examples
 
 ### 1. Direct connections without NAT or STUN
 
-In this example, both the client and agent are located on the network
-`192.168.21.0/24`. Assuming no firewalls are blocking packets in either
-direction, both client and agent are able to communicate directly with each
+In this example, both the client and workspace daemon are located on the
+network `192.168.21.0/24`. Assuming no firewalls are blocking packets in either
+direction, both client and workspace daemon are able to communicate directly
+with each
 other's locally assigned IP address.
 
-![Diagram of a workspace agent and client in the same network](../../images/networking/stun1.png)
+![Diagram of a workspace daemon and client in the same network](../../images/networking/stun1.png)
 
 ### 2. Direct connections with one layer of NAT
 
-In this example, client and agent are located on different networks and connect
-to each other over the public Internet. Both client and agent connect to a
+In this example, client and workspace daemon are located on different networks
+and connect to each other over the public Internet. Both client and workspace
+daemon connect to a
 configured STUN server located on the public Internet to determine the public IP
 address and port on which they can be reached.
 
-![Diagram of a workspace agent and client in separate networks](../../images/networking/stun2.1.png)
+![Diagram of a workspace daemon and client in separate networks](../../images/networking/stun2.1.png)
 
 They then exchange this information through Coder server, and can then
 communicate directly with each other through their respective NATs.
 
-![Diagram of a workspace agent and client in separate networks](../../images/networking/stun2.2.png)
+![Diagram of a workspace daemon and client in separate networks](../../images/networking/stun2.2.png)
 
 ### 3. Direct connections with VPN and NAT hairpinning
 
@@ -93,36 +96,37 @@ address of the VPN exit node `172.16.1.2`. Traffic from the client to the public
 internet will appear to have the public IP address of the corporate router
 `12.34.56.7`.
 
-The workspace agent is running on a Kubernetes cluster inside the corporate
+The workspace daemon is running on a Kubernetes cluster inside the corporate
 network, which is behind its own layer of NAT. To anyone inside the corporate
 network but outside the cluster network, its traffic will appear to be coming
-from `172.16.1.254`. However, traffic from the agent to services on the public
+from `172.16.1.254`. However, traffic from the workspace daemon to services on the public
 Internet will also see traffic originating from the public IP address assigned
 to the corporate router. Additionally, the corporate router will most likely
 have a firewall configured to block traffic from the internet to the corporate
 network.
 
-If the client and agent both use the public STUN server, the addresses
+If the client and workspace daemon both use the public STUN server, the addresses
 discovered by STUN will both be the public IP address of the corporate router.
 To correctly route the traffic backwards, the corporate router must correctly
 route both:
 
 - Traffic sent from the client to the external IP of the corporate router back
   to the cluster router, and
-- Traffic sent from the agent to the external IP of the corporate router to the
+- Traffic sent from the workspace daemon to the external IP of the corporate router to the
   VPN exit node.
 
 This behaviour is known as "hairpinning", and may not be supported in all
 network configurations.
 
 If hairpinning is not supported, deploying an internal STUN server can aid
-establishing direct connections between client and agent. When the agent and
-client query this internal STUN server, they will be able to determine the
+establishing direct connections between client and workspace daemon. When the
+workspace daemon and client query this internal STUN server, they will be able
+to determine the
 addresses on the corporate network from which their traffic appears to
 originate. Using these internal addresses is much more likely to result in a
 successful direct connection.
 
-![Diagram of a workspace agent and client over VPN](../../images/networking/stun3.png)
+![Diagram of a workspace daemon and client over VPN](../../images/networking/stun3.png)
 
 ## Hard NAT
 

docs/admin/networking/troubleshooting.md

@@ -1,8 +1,9 @@
 # Troubleshooting
 
-`coder ping <workspace>` will ping the workspace agent and print diagnostics on
-the state of the connection. These diagnostics are created by inspecting both
-the client and agent network configurations, and provide insights into why a
+`coder ping <workspace>` will ping the workspace daemon and print diagnostics
+on the state of the connection. These diagnostics are created by inspecting
+both the client and workspace daemon network configurations, and provide
+insights into why a
 direct connection may be impeded, or why the quality of one might be degraded.
 
 The `-v/--verbose` flag can be appended to the command to print client debug
@@ -41,13 +42,14 @@ flag on the server. When set, this will be reflected in the output of
 ### UDP Blocked
 
 Some corporate firewalls block UDP traffic. Direct connections require UDP
-traffic to be allowed between the client and agent, as well as between the
-client/agent and STUN servers in most cases. `coder ping` will indicate if
-either the Coder agent or client had issues sending or receiving UDP packets to
+traffic to be allowed between the client and workspace daemon, as well as
+between the client/workspace daemon and STUN servers in most cases.
+`coder ping` will indicate if either the workspace daemon or client had issues
+sending or receiving UDP packets to
 STUN servers.
 
-If this is the case, you may need to add exceptions to the firewall to allow UDP
-for Coder workspaces, clients, and STUN servers.
+If this is the case, you may need to add exceptions to the firewall to allow
+UDP for Coder workspaces, clients, and STUN servers.
 
 ### Endpoint-Dependent NAT (Hard NAT)
 
@@ -57,7 +59,7 @@ connection is behind a hard NAT, direct connections can still be established
 easily. However, if both sides are behind hard NATs, direct connections may take
 longer to establish or may not be possible at all.
 
-`coder ping` will indicate if it's possible the client or agent is behind a hard
+`coder ping` will indicate if it's possible the client or workspace daemon is behind a hard
 NAT.
 
 Learn more about [STUN and NAT](./stun.md).
@@ -65,8 +67,9 @@ Learn more about [STUN and NAT](./stun.md).
 ### No STUN Servers
 
 If there are no STUN servers available within a deployment's DERP MAP, direct
-connections may not be possible. Notable exceptions are if the client and agent
-are on the same network, or if either is able to use UPnP instead of STUN to
+connections may not be possible. Notable exceptions are if the client and
+workspace daemon are on the same network, or if either is able to use UPnP
+instead of STUN to
 resolve the public IP of the other. `coder ping` will indicate if no STUN
 servers were found.
 
@@ -82,23 +85,23 @@ firewall, or reconfigure the hard NAT.
 ### VPNs
 
 If a VPN is the default route for all IP traffic, it may interfere with the
-ability for clients and agents to form direct connections. This happens if the
+ability for clients and workspace daemons to form direct connections. This happens if the
 NAT does not permit traffic to be
 ['hairpinned'](./stun.md#3-direct-connections-with-vpn-and-nat-hairpinning) from
 the public IP address of the NAT (determined via STUN) to the internal IP
-address of the agent.
+address of the workspace daemon.
 
 If this is the case, you may need to add exceptions to the VPN for Coder, modify
 the NAT configuration, or deploy an internal STUN server.
 
 ### Low MTU
 
-If a network interface on the side of either the client or agent has an MTU
+If a network interface on the side of either the client or workspace daemon has an MTU
 smaller than 1378, any direct connections form may have degraded quality or
 might hang entirely.
 
 Use `coder ping` to check for MTU issues, as it inspects
-network interfaces on both the client and the workspace agent:
+network interfaces on both the client and the workspace daemon:
 
 ```console
 $ coder ping my-workspace
@@ -119,7 +122,7 @@ flag or `CODER_BLOCK_DIRECT` environment variable on the Coder server.
 ## Throughput
 
 The `coder speedtest <workspace>` command measures the throughput between the
-client and the workspace agent.
+client and the workspace daemon.
 
 ```console
 $ coder speedtest workspace

docs/admin/networking/wildcard-access-url.md

@@ -104,7 +104,7 @@ In your Coder templates, enable subdomain applications using the `subdomain` par
 
 ```hcl
 resource "coder_app" "code-server" {
-  agent_id     = coder_agent.main.id
+  agent_id     = coder_workspace_daemon.main.id
   slug         = "code-server"
   display_name = "VS Code"
   url          = "http://localhost:8080"

docs/admin/security/audit-logs.md

@@ -186,7 +186,7 @@ You may choose to run a `VACUUM` or `VACUUM FULL` operation on the audit logs ta
   WHERE pg_stat_activity.datname = 'coder' AND pid <> pg_backend_pid();
   ```
 
-- **Only `coderd` needs to scale down** - external provisioner daemons, workspace proxies, and workspace agents don't connect to the database directly.
+- **Only `coderd` needs to scale down** - external provisioner daemons, workspace proxies, and workspace daemons don't connect to the database directly.
 
 After the vacuum completes, scale coderd back up:
 

docs/admin/security/secrets.md

@@ -60,7 +60,7 @@ resource "twilio_iam_api_key" "api_key" {
   friendly_name = "Test API Key"
 }
 
-resource "coder_agent" "main" {
+resource "coder_workspace_daemon" "main" {
   # ...
   env = {
     # Let users access the secret via $TWILIO_API_SECRET

docs/admin/setup/data-retention.md

@@ -1,7 +1,7 @@
 # Data Retention
 
 Coder supports configurable retention policies that automatically purge old
-Audit Logs, Connection Logs, Workspace Agent Logs, API keys, and AI Bridge
+Audit Logs, Connection Logs, Workspace Daemon Logs, API keys, and AI Bridge
 records. These policies help manage database growth by removing records older
 than a specified duration.
 
@@ -17,7 +17,7 @@ Retention policies help you:
 
 > [!NOTE]
 > Retention policies are disabled by default (set to `0`) to preserve existing
-> behavior. The exceptions are API keys and workspace agent logs, which default
+> behavior. The exceptions are API keys and workspace daemon logs, which default
 > to 7 days.
 
 ## Configuration
@@ -32,7 +32,7 @@ a YAML configuration file.
 | Audit Logs           | `--audit-logs-retention`           | `CODER_AUDIT_LOGS_RETENTION`           | `0` (disabled) | How long to retain Audit Log entries    |
 | Connection Logs      | `--connection-logs-retention`      | `CODER_CONNECTION_LOGS_RETENTION`      | `0` (disabled) | How long to retain Connection Logs      |
 | API Keys             | `--api-keys-retention`             | `CODER_API_KEYS_RETENTION`             | `7d`           | How long to retain expired API keys     |
-| Workspace Agent Logs | `--workspace-agent-logs-retention` | `CODER_WORKSPACE_AGENT_LOGS_RETENTION` | `7d`           | How long to retain workspace agent logs |
+| Workspace Daemon Logs | `--workspace-agent-logs-retention` | `CODER_WORKSPACE_AGENT_LOGS_RETENTION` | `7d`           | How long to retain workspace daemon logs |
 | AI Bridge            | `--aibridge-retention`             | `CODER_AIBRIDGE_RETENTION`             | `60d`          | How long to retain AI Bridge records    |
 
 > [!NOTE]
@@ -117,16 +117,16 @@ ago. Active keys are never deleted by the retention policy.
 Keeping expired keys for a short period allows Coder to return a more helpful
 error message when users attempt to use an expired key.
 
-### Workspace Agent Logs Behavior
+### Workspace Daemon Logs Behavior
 
-Workspace agent logs are deleted based on when the agent last connected, not the
+Workspace daemon logs are deleted based on when the workspace daemon last connected, not the
 age of the logs themselves. **Logs from the latest build of each workspace are
-always retained** regardless of when the agent last connected. This ensures you
+always retained** regardless of when the workspace daemon last connected. This ensures you
 can always debug issues with active workspaces.
 
-For non-latest builds, logs are deleted if the agent hasn't connected within the
+For non-latest builds, logs are deleted if the workspace daemon hasn't connected within the
 retention period. Setting `--workspace-agent-logs-retention=7d` deletes logs for
-agents that haven't connected in 7 days (excluding those from the latest build).
+workspace daemons that haven't connected in 7 days (excluding those from the latest build).
 
 ### AI Bridge Data Behavior
 

docs/admin/templates/creating-templates.md

@@ -151,7 +151,7 @@ Refer to the following resources:
 
 - [Tutorial: Create a template from scratch](../../tutorials/template-from-scratch.md)
 - [Extending templates](./extending-templates/index.md): Features and concepts
-  around templates (agents, parameters, variables, etc)
+  around templates (workspace daemons, parameters, variables, etc)
 - [Coder Registry](https://registry.coder.com/templates): Official and community
   templates for Coder
 - [Coder Terraform Provider Reference](https://registry.terraform.io/providers/coder/coder)

docs/admin/templates/extending-templates/agent-metadata.md

@@ -1,12 +1,12 @@
-# Agent metadata
+# Workspace daemon metadata
 
 ![agent-metadata](../../../images/admin/templates/agent-metadata-ui.png)
 
-You can show live operational metrics to workspace users with agent metadata. It
+You can show live operational metrics to workspace users with workspace daemon metadata. It
 is the dynamic complement of [resource metadata](./resource-metadata.md).
 
-You specify agent metadata in the
-[`coder_agent`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent).
+You specify workspace daemon metadata in the
+[`coder_workspace_daemon`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent).
 
 ## Examples
 
@@ -20,10 +20,10 @@ command. This is useful for determining CPU and memory usage of the VM or
 container that the workspace is running in, which is more accurate than resource
 usage about the workspace's host.
 
-Here's a standard set of metadata snippets for Linux agents:
+Here's a standard set of metadata snippets for Linux workspace daemons:
 
 ```tf
-resource "coder_agent" "main" {
+resource "coder_workspace_daemon" "main" {
   os             = "linux"
   ...
   metadata {
@@ -88,7 +88,7 @@ resource "coder_agent" "main" {
 
 ## Useful utilities
 
-You can also show agent metadata for information about the workspace's host.
+You can also show workspace daemon metadata for information about the workspace's host.
 
 [top](https://manpages.ubuntu.com/manpages/jammy/en/man1/top.1.html) is
 available in most Linux distributions and provides virtual memory, CPU and IO
@@ -123,7 +123,7 @@ usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw
 
 ## Managing the database load
 
-Agent metadata can generate a significant write load and overwhelm your Coder
+Workspace daemon metadata can generate a significant write load and overwhelm your Coder
 database if you're not careful. The approximate writes per second can be
 calculated using the formula:
 
@@ -133,7 +133,7 @@ calculated using the formula:
 
 For example, let's say you have
 
-- 10 running agents
+- 10 running workspace daemons
 - each with 6 metadata snippets
 - with an average interval of 4 seconds
 

docs/admin/templates/extending-templates/docker-in-workspaces.md

@@ -28,13 +28,13 @@ resource "docker_container" "workspace" {
   # ...
   name    = "coder-${data.coder_workspace.me.owner}-${lower(data.coder_workspace.me.name)}"
   image   = "codercom/enterprise-base:ubuntu"
-  env     = ["CODER_AGENT_TOKEN=${coder_agent.main.token}"]
-  command = ["sh", "-c", coder_agent.main.init_script]
+  env     = ["CODER_AGENT_TOKEN=${coder_workspace_daemon.main.token}"]
+  command = ["sh", "-c", coder_workspace_daemon.main.init_script]
   # Use the Sysbox container runtime (required)
   runtime = "sysbox-runc"
 }
 
-resource "coder_agent" "main" {
+resource "coder_workspace_daemon" "main" {
   arch           = data.coder_provisioner.me.arch
   os             = "linux"
   startup_script = <<EOF
@@ -74,7 +74,7 @@ variable "workspaces_namespace" {
 
 data "coder_workspace" "me" {}
 
-resource "coder_agent" "main" {
+resource "coder_workspace_daemon" "main" {
   os   = "linux"
   arch = "amd64"
   dir  = "/home/coder"
@@ -109,10 +109,10 @@ resource "kubernetes_pod" "dev" {
       name = "dev"
       env {
         name  = "CODER_AGENT_TOKEN"
-        value = coder_agent.main.token
+        value = coder_workspace_daemon.main.token
       }
       image = "codercom/enterprise-base:ubuntu"
-      command = ["sh", "-c", coder_agent.main.init_script]
+      command = ["sh", "-c", coder_workspace_daemon.main.init_script]
     }
   }
 }
@@ -318,7 +318,7 @@ your nodes cannot run Sysbox.
 ### Use a privileged sidecar container in Docker-based templates
 
 ```tf
-resource "coder_agent" "main" {
+resource "coder_workspace_daemon" "main" {
   os             = "linux"
   arch           = "amd64"
 }
@@ -341,9 +341,9 @@ resource "docker_container" "workspace" {
   count   = data.coder_workspace.me.start_count
   image   = "codercom/enterprise-base:ubuntu"
   name    = "dev-${data.coder_workspace.me.id}"
-  command = ["sh", "-c", coder_agent.main.init_script]
+  command = ["sh", "-c", coder_workspace_daemon.main.init_script]
   env = [
-    "CODER_AGENT_TOKEN=${coder_agent.main.token}",
+    "CODER_AGENT_TOKEN=${coder_workspace_daemon.main.token}",
     "DOCKER_HOST=${docker_container.dind.name}:2375"
   ]
   networks_advanced {
@@ -373,7 +373,7 @@ variable "workspaces_namespace" {
 
 data "coder_workspace" "me" {}
 
-resource "coder_agent" "main" {
+resource "coder_workspace_daemon" "main" {
   os             = "linux"
   arch           = "amd64"
 }
@@ -398,13 +398,13 @@ resource "kubernetes_pod" "main" {
     container {
       name    = "dev"
       image   = "codercom/enterprise-base:ubuntu"
-      command = ["sh", "-c", coder_agent.main.init_script]
+      command = ["sh", "-c", coder_workspace_daemon.main.init_script]
       security_context {
         run_as_user = "1000"
       }
       env {
         name  = "CODER_AGENT_TOKEN"
-        value = coder_agent.main.token
+        value = coder_workspace_daemon.main.token
       }
       # Use the Docker daemon in the "docker-sidecar" container
       env {
@@ -445,7 +445,7 @@ variable "workspaces_namespace" {
 
 data "coder_workspace" "me" {}
 
-resource "coder_agent" "main" {
+resource "coder_workspace_daemon" "main" {
   os   = "linux"
   arch = "amd64"
   dir  = "/home/coder"
@@ -476,11 +476,11 @@ resource "kubernetes_pod" "dev" {
       name = "dev"
       env {
         name  = "CODER_AGENT_TOKEN"
-        value = coder_agent.main.token
+        value = coder_workspace_daemon.main.token
       }
       image = "codercom/enterprise-base:ubuntu"
       command = ["sh", "-c", <<EOF
-    # Start the Coder agent as the "coder" user
+    # Start the Coder workspace daemon as the "coder" user
     # once systemd has started up
     sudo -u coder --preserve-env=CODER_AGENT_TOKEN /bin/bash -- <<-'    EOT' &
     while [[ ! $(systemctl is-system-running) =~ ^(running|degraded) ]]
@@ -488,7 +488,7 @@ resource "kubernetes_pod" "dev" {
       echo "Waiting for system to start... $(systemctl is-system-running)"
       sleep 2
     done
-    ${coder_agent.main.init_script}
+    ${coder_workspace_daemon.main.init_script}
     EOT
 
     exec /sbin/init

docs/admin/templates/extending-templates/external-auth.md

@@ -34,7 +34,7 @@ you can require users authenticate via git prior to creating a workspace:
 > [!TIP]
 > This is the preferred authentication method.
 
-By default, the coder agent will configure native `git` authentication via the
+By default, the workspace daemon will configure native `git` authentication via the
 `GIT_ASKPASS` environment variable. Meaning, with no additional configuration,
 external authentication will work with native `git` commands.
 
@@ -73,7 +73,7 @@ data "coder_external_auth" "github" {
   id = "github"
 }
 
-resource "coder_agent" "dev" {
+resource "coder_workspace_daemon" "dev" {
   os   = "linux"
   arch = "amd64"
   dir  = "~/coder"

docs/admin/templates/extending-templates/index.md

@@ -9,17 +9,17 @@ view our
 [example templates](https://github.com/coder/coder/tree/main/examples/templates)
 to get started.
 
-## Workspace agents
+## Workspace daemons
 
 For users to connect to a workspace, the template must include a
-[`coder_agent`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent).
-The associated agent will facilitate
+[`coder_workspace_daemon`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent).
+The associated workspace daemon will facilitate
 [workspace connections](../../../user-guides/workspace-access/index.md) via SSH,
-port forwarding, and IDEs. The agent may also display real-time
-[workspace metadata](./agent-metadata.md) like resource usage.
+port forwarding, and IDEs. The workspace daemon may also display real-time
+[workspace daemon metadata](./agent-metadata.md) like resource usage.
 
 ```tf
-resource "coder_agent" "dev" {
+resource "coder_workspace_daemon" "dev" {
   os   = "linux"
   arch = "amd64"
   dir  = "/workspace"
@@ -32,14 +32,14 @@ resource "coder_agent" "dev" {
 You can also leverage [resource metadata](./resource-metadata.md) to display
 static resource information from your template.
 
-Templates must include some computational resource to start the agent. All
-processes on the workspace are then spawned from the agent. It also provides all
+Templates must include some computational resource to start the workspace daemon. All
+processes on the workspace are then spawned from the workspace daemon. It also provides all
 information displayed in the dashboard's workspace view.
 
-![A healthy workspace agent](../../../images/templates/healthy-workspace-agent.png)
+![A healthy workspace daemon](../../../images/templates/healthy-workspace-agent.png)
 
-Multiple agents may be used in a single template or even a single resource. Each
-agent may have its own apps, startup script, and metadata. This can be used to
+Multiple workspace daemons may be used in a single template or even a single resource. Each
+workspace daemon may have its own apps, startup script, and metadata. This can be used to
 associate multiple containers or VMs with a workspace.
 
 ## Resource persistence
@@ -80,10 +80,10 @@ resource.
 
 ![Coder Apps in the dashboard](../../../images/admin/templates/coder-apps-ui.png)
 
-Note that some apps are associated to the agent by default as
+Note that some apps are associated to the workspace daemon by default as
 [`display_apps`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent#nested-schema-for-display_apps)
 and can be hidden directly in the
-[`coder_agent`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent)
+[`coder_workspace_daemon`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent)
 resource. You can arrange the display orientation of Coder apps in your template
 using [resource ordering](./resource-ordering.md).
 
@@ -97,7 +97,7 @@ You can use these examples to add new Coder apps:
 
 ```hcl
 resource "coder_app" "code-server" {
-  agent_id     = coder_agent.main.id
+  agent_id     = coder_workspace_daemon.main.id
   slug         = "code-server"
   display_name = "code-server"
   url          = "http://localhost:13337/?folder=/home/${local.username}"
@@ -111,7 +111,7 @@ resource "coder_app" "code-server" {
 
 ```hcl
 resource "coder_app" "filebrowser" {
-  agent_id     = coder_agent.main.id
+  agent_id     = coder_workspace_daemon.main.id
   display_name = "file browser"
   slug         = "filebrowser"
   url          = "http://localhost:13339"
@@ -125,7 +125,7 @@ resource "coder_app" "filebrowser" {
 
 ```hcl
 resource "coder_app" "zed" {
-    agent_id = coder_agent.main.id
+    agent_id = coder_workspace_daemon.main.id
     slug          = "slug"
     display_name  = "Zed"
     external = true
@@ -145,7 +145,7 @@ The
 [`coder_script`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/script)
 resource runs scripts during workspace lifecycle events like startup, stop, or
 on a scheduled basis. It provides more control than the deprecated
-`startup_script` field in `coder_agent`.
+`startup_script` field in `coder_workspace_daemon`.
 
 ### When to use coder_script
 
@@ -159,7 +159,7 @@ on a scheduled basis. It provides more control than the deprecated
 
 ```tf
 resource "coder_script" "install_dependencies" {
-  agent_id           = coder_agent.main.id
+  agent_id           = coder_workspace_daemon.main.id
   display_name       = "Install Dependencies"
   icon               = "/icon/package.svg"
   script             = <<-EOF
@@ -200,7 +200,7 @@ You can also reference external script files:
 
 ```tf
 resource "coder_script" "init_docker" {
-  agent_id     = coder_agent.main.id
+  agent_id     = coder_workspace_daemon.main.id
   display_name = "Initialize Docker"
   script       = file("${path.module}/scripts/init-docker.sh")
   run_on_start = true

docs/admin/templates/extending-templates/jetbrains-preinstall.md

@@ -47,7 +47,7 @@ module "jetbrains_gateway" {
   count          = data.coder_workspace.me.start_count
   source         = "registry.coder.com/modules/jetbrains-gateway/coder"
   version        = "1.0.29"
-  agent_id       = coder_agent.main.id
+  agent_id       = coder_workspace_daemon.main.id
   folder         = "/home/coder/example"
   jetbrains_ides = ["IU"]
   default        = "IU"
@@ -60,7 +60,7 @@ module "jetbrains_gateway" {
   }
 }
 
-resource "coder_agent" "main" {
+resource "coder_workspace_daemon" "main" {
     ...
     startup_script = <<-EOF
     ~/JetBrains/*/bin/remote-dev-server.sh registerBackendLocationForGateway

docs/admin/templates/extending-templates/modules.md

@@ -20,7 +20,7 @@ module "coder-base" {
   code_server_version = 4.14.1
 }
 
-resource "coder_agent" "dev" {
+resource "coder_workspace_daemon" "dev" {
   # Modules can provide outputs, such as helper scripts
   startup_script=<<EOF
   #!/bin/sh
@@ -109,7 +109,7 @@ to resolve modules via [Artifactory](https://jfrog.com/artifactory/).
    module "module-name" {
      source = "https://example.jfrog.io/tf__coder/module-name/coder"
      version = "1.0.0"
-     agent_id = coder_agent.example.id
+     agent_id = coder_workspace_daemon.example.id
      ...
    }
    ```

docs/admin/templates/extending-templates/prebuilt-workspaces.md

@@ -79,11 +79,11 @@ Prebuilt workspaces follow a specific lifecycle from creation through eligibilit
    Before a prebuilt workspace is available to users:
 
    1. The workspace is provisioned.
-   1. The agent starts up and connects to coderd.
-   1. The agent starts its bootstrap procedures and completes its startup scripts.
-   1. The agent reports `ready` status.
+   1. The workspace daemon starts up and connects to coderd.
+   1. The workspace daemon starts its bootstrap procedures and completes its startup scripts.
+   1. The workspace daemon reports `ready` status.
 
-      After the agent reports `ready`, the prebuilt workspace considered eligible to be claimed.
+      After the workspace daemon reports `ready`, the prebuilt workspace considered eligible to be claimed.
 
    Prebuilt workspaces that fail during provisioning are retried with a backoff to prevent transient failures.
 

docs/admin/templates/extending-templates/process-logging.md

@@ -85,7 +85,7 @@ would like to add workspace process logging to, follow these steps:
    ```hcl
    locals {
      # This is the init script for the main workspace container that runs before the
-     # agent starts to configure workspace process logging.
+     # workspace daemon starts to configure workspace process logging.
      exectrace_init_script = <<EOT
        set -eu
        pidns_inum=$(readlink /proc/self/ns/pid | sed 's/[^0-9]//g')
@@ -154,7 +154,7 @@ would like to add workspace process logging to, follow these steps:
          command = [
            "sh",
            "-c",
-           "${local.exectrace_init_script}\n\n${coder_agent.main.init_script}",
+           "${local.exectrace_init_script}\n\n${coder_workspace_daemon.main.init_script}",
          ]
          ...
        }

docs/admin/templates/extending-templates/resource-metadata.md

@@ -17,7 +17,7 @@ You can use `coder_metadata` to show Terraform resource attributes like these:
 > Coder automatically generates the <code>type</code> metadata.
 
 You can also present automatically updating, dynamic values with
-[agent metadata](./agent-metadata.md).
+[workspace daemon metadata](./agent-metadata.md).
 
 ## Example
 
@@ -107,4 +107,4 @@ how to use the builtin icons [here](./icons.md).
 ## Up next
 
 - [Secrets](../../security/secrets.md)
-- [Agent metadata](./agent-metadata.md)
+- [Workspace daemon metadata](./agent-metadata.md)

docs/admin/templates/extending-templates/resource-monitoring.md

@@ -3,14 +3,14 @@
 Use the
 [`resources_monitoring`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent#resources_monitoring-1)
 block on the
-[`coder_agent`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent)
+[`coder_workspace_daemon`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent)
 resource in our Terraform provider to monitor out of memory (OOM) and out of
 disk (OOD) errors and alert users when they overutilize memory and disk.
 
-This can help prevent agent disconnects due to OOM/OOD issues.
+This can help prevent workspace daemon disconnects due to OOM/OOD issues.
 
 You can specify one or more volumes to monitor for OOD alerts.
-OOM alerts are reported per-agent.
+OOM alerts are reported per-workspace daemon.
 
 ## Prerequisites
 
@@ -24,7 +24,7 @@ Change the `90`, `80`, and `95` to a threshold that's more appropriate for your
 deployment:
 
 ```hcl
-resource "coder_agent" "main" {
+resource "coder_workspace_daemon" "main" {
   arch = data.coder_provisioner.dev.arch
   os   = data.coder_provisioner.dev.os
   resources_monitoring {

docs/admin/templates/extending-templates/resource-ordering.md

@@ -32,35 +32,35 @@ data "coder_parameter" "account_id" {
 }
 ```
 
-### Agents
+### Workspace daemons
 
-Agent resources within the UI left pane are sorted based on the `order`
+Workspace daemon resources within the UI left pane are sorted based on the `order`
 property, followed by `name`, ensuring a consistent and intuitive arrangement.
 
 ```tf
-resource "coder_agent" "primary" {
+resource "coder_workspace_daemon" "primary" {
   ...
 
   order = 1
 }
 
-resource "coder_agent" "secondary" {
+resource "coder_workspace_daemon" "secondary" {
   ...
 
   order = 2
 }
 ```
 
-The agent with the lowest order is presented at the top in the workspace view.
+The workspace daemon with the lowest order is presented at the top in the workspace view.
 
-### Agent metadata
+### Workspace daemon metadata
 
-The `coder_agent` exposes metadata to present operational metrics in the UI.
+The `coder_workspace_daemon` exposes metadata to present operational metrics in the UI.
 Metrics defined with Terraform `metadata` blocks can be ordered using additional
 `order` property; otherwise, they are sorted by `key`.
 
 ```tf
-resource "coder_agent" "main" {
+resource "coder_workspace_daemon" "main" {
   ...
 
   metadata {
@@ -100,8 +100,8 @@ resource "coder_agent" "main" {
 
 ### Applications
 
-Similarly to Coder agents, `coder_app` resources incorporate the `order`
-property to organize button apps in the app bar within a `coder_agent` in the
+Similarly to workspace daemons, `coder_app` resources incorporate the `order`
+property to organize button apps in the app bar within a `coder_workspace_daemon` in the
 workspace view.
 
 Only template defined applications can be arranged. _VS Code_ or _Terminal_
@@ -109,7 +109,7 @@ buttons are static.
 
 ```tf
 resource "coder_app" "code-server" {
-  agent_id     = coder_agent.main.id
+  agent_id     = coder_workspace_daemon.main.id
   slug         = "code-server"
   display_name = "code-server"
   ...
@@ -118,7 +118,7 @@ resource "coder_app" "code-server" {
 }
 
 resource "coder_app" "filebrowser" {
-  agent_id     = coder_agent.main.id
+  agent_id     = coder_workspace_daemon.main.id
   display_name = "File Browser"
   slug         = "filebrowser"
   ...

docs/admin/templates/extending-templates/web-ides.md

@@ -9,7 +9,7 @@ used as a Coder application. For example:
 # Add button to open Portainer in the workspace dashboard
 # Note: Portainer must be already running in the workspace
 resource "coder_app" "portainer" {
-  agent_id      = coder_agent.main.id
+  agent_id      = coder_workspace_daemon.main.id
   slug          = "portainer"
   display_name  = "Portainer"
   icon          = "https://simpleicons.org/icons/portainer.svg"
@@ -27,7 +27,7 @@ resource "coder_app" "portainer" {
 
 [code-server](https://github.com/coder/code-server) is our supported method of running
 VS Code in the web browser. A simple way to install code-server in Linux/macOS
-workspaces is via the Coder agent in your template:
+workspaces is via the workspace daemon in your template:
 
 ```console
 # edit your template
@@ -36,7 +36,7 @@ vim main.tf
 ```
 
 ```tf
-resource "coder_agent" "main" {
+resource "coder_workspace_daemon" "main" {
     arch           = "amd64"
     os             = "linux"
     startup_script = <<EOF
@@ -68,16 +68,16 @@ USER coder
 # pre-install VS Code extensions
 RUN code-server --install-extension eamodio.gitlens
 
-# directly start code-server with the agent's startup_script (see above),
+# directly start code-server with the workspace daemon's startup_script (see above),
 # or use a process manager like supervisord
 ```
 
-You'll also need to specify a `coder_app` resource related to the agent. This is
+You'll also need to specify a `coder_app` resource related to the workspace daemon. This is
 how code-server is displayed on the workspace page.
 
 ```tf
 resource "coder_app" "code-server" {
-  agent_id     = coder_agent.main.id
+  agent_id     = coder_workspace_daemon.main.id
   slug         = "code-server"
   display_name = "code-server"
   url          = "http://localhost:13337/?folder=/home/coder"
@@ -108,16 +108,15 @@ command. To add VS Code web as a web IDE, you have two options.
    module "vscode-web" {
      source         = "registry.coder.com/modules/vscode-web/coder"
      version        = "1.0.14"
-     agent_id       = coder_agent.main.id
-     accept_license = true
-   }
+   agent_id       = coder_workspace_daemon.main.id
+   accept_license = true   }
    ```
 
 2. Install and start in your `startup_script` and create a corresponding
    `coder_app`
 
    ```tf
-   resource "coder_agent" "main" {
+   resource "coder_workspace_daemon" "main" {
        arch           = "amd64"
        os             = "linux"
        startup_script = <<EOF
@@ -140,7 +139,7 @@ command. To add VS Code web as a web IDE, you have two options.
    ```tf
    # VS Code Web
    resource "coder_app" "vscode-web" {
-     agent_id     = coder_agent.coder.id
+     agent_id     = coder_workspace_daemon.coder.id
      slug         = "vscode-web"
      display_name = "VS Code Web"
      icon         = "/icon/code.svg"
@@ -160,7 +159,7 @@ from the Coder registry:
 module "jupyter-notebook" {
   source   = "registry.coder.com/modules/jupyter-notebook/coder"
   version  = "1.0.19"
-  agent_id = coder_agent.example.id
+  agent_id = coder_workspace_daemon.example.id
 }
 ```
 
@@ -168,13 +167,13 @@ module "jupyter-notebook" {
 
 ## JupyterLab
 
-Configure your agent and `coder_app` like so to use Jupyter. Notice the
+Configure your workspace daemon and `coder_app` like so to use Jupyter. Notice the
 `subdomain=true` configuration:
 
 ```tf
 data "coder_workspace" "me" {}
 
-resource "coder_agent" "coder" {
+resource "coder_workspace_daemon" "coder" {
   os             = "linux"
   arch           = "amd64"
   dir            = "/home/coder"
@@ -185,7 +184,7 @@ EOF
 }
 
 resource "coder_app" "jupyter" {
-  agent_id     = coder_agent.coder.id
+  agent_id     = coder_workspace_daemon.coder.id
   slug         = "jupyter"
   display_name = "JupyterLab"
   url          = "http://localhost:8888"
@@ -207,7 +206,7 @@ Or Alternatively, you can use the JupyterLab module from the Coder registry:
 module "jupyter" {
   source   = "registry.coder.com/modules/jupyter-lab/coder"
   version  = "1.0.0"
-  agent_id = coder_agent.main.id
+  agent_id = coder_workspace_daemon.main.id
 }
 ```
 
@@ -222,11 +221,11 @@ value substitution to recreate the path structure.
 
 ## RStudio
 
-Configure your agent and `coder_app` like so to use RStudio. Notice the
+Configure your workspace daemon and `coder_app` like so to use RStudio. Notice the
 `subdomain=true` configuration:
 
 ```tf
-resource "coder_agent" "coder" {
+resource "coder_workspace_daemon" "coder" {
   os             = "linux"
   arch           = "amd64"
   dir            = "/home/coder"
@@ -238,7 +237,7 @@ EOT
 }
 
 resource "coder_app" "rstudio" {
-  agent_id      = coder_agent.coder.id
+  agent_id      = coder_workspace_daemon.coder.id
   slug          = "rstudio"
   display_name  = "R Studio"
   icon          = "https://upload.wikimedia.org/wikipedia/commons/d/d0/RStudio_logo_flat.svg"
@@ -269,11 +268,11 @@ community template example.
 
 ## Airflow
 
-Configure your agent and `coder_app` like so to use Airflow. Notice the
+Configure your workspace daemon and `coder_app` like so to use Airflow. Notice the
 `subdomain=true` configuration:
 
 ```tf
-resource "coder_agent" "coder" {
+resource "coder_workspace_daemon" "coder" {
   os   = "linux"
   arch = "amd64"
   dir  = "/home/coder"
@@ -286,7 +285,7 @@ EOT
 }
 
 resource "coder_app" "airflow" {
-  agent_id      = coder_agent.coder.id
+  agent_id      = coder_workspace_daemon.coder.id
   slug          = "airflow"
   display_name  = "Airflow"
   icon          = "/icon/airflow.svg"
@@ -309,7 +308,7 @@ from the Coder registry:
 module "airflow" {
   source   = "registry.coder.com/modules/airflow/coder"
   version  = "1.0.13"
-  agent_id = coder_agent.main.id
+  agent_id = coder_workspace_daemon.main.id
 }
 ```
 
@@ -324,7 +323,7 @@ manipulate files in a web browser.
 Show and manipulate the contents of the `/home/coder` directory in a browser.
 
 ```tf
-resource "coder_agent" "coder" {
+resource "coder_workspace_daemon" "coder" {
   os   = "linux"
   arch = "amd64"
   dir  = "/home/coder"
@@ -338,7 +337,7 @@ EOT
 }
 
 resource "coder_app" "filebrowser" {
-  agent_id     = coder_agent.coder.id
+  agent_id     = coder_workspace_daemon.coder.id
   display_name = "file browser"
   slug         = "filebrowser"
   url          = "http://localhost:13339"
@@ -362,7 +361,7 @@ Coder registry:
 module "filebrowser" {
   source   = "registry.coder.com/modules/filebrowser/coder"
   version  = "1.0.8"
-  agent_id = coder_agent.main.id
+  agent_id = coder_workspace_daemon.main.id
 }
 ```
 

docs/admin/templates/managing-templates/external-workspaces.md

@@ -4,7 +4,7 @@ External workspaces allow you to seamlessly connect externally managed infrastru
 
 ## Prerequisites
 
-- Access to external compute resources that can run the Coder agent:
+- Access to external compute resources that can run the workspace daemon:
   - **Windows**: amd64 or arm64 architecture
   - **Linux**: amd64, arm64, or armv7 architecture
   - **macOS**: amd64 or arm64 architecture
@@ -28,7 +28,7 @@ External workspaces offer flexibility and control in complex environments:
 
 - **Separation of concerns**
 
-  Provision compute resources externally (using your existing IaC or manual processes) while managing workspace configuration (apps, scripts) with Terraform. This approach is ideal for running agents in CI pipelines to provision short-lived, externally managed workspaces for testing or build automation.
+  Provision compute resources externally (using your existing IaC or manual processes) while managing workspace configuration (apps, scripts) with Terraform. This approach is ideal for running workspace daemons in CI pipelines to provision short-lived, externally managed workspaces for testing or build automation.
 
 ## Known limitations
 
@@ -37,10 +37,10 @@ External workspaces offer flexibility and control in complex environments:
   Start/stop/restart actions in the Coder UI are disabled for external workspaces.
 - **No automatic deprovisioning**
 
-  Deleting an external workspace in Coder removes the agent token and record, but does not delete the underlying compute resource.
-- **Manual agent management**
+  Deleting an external workspace in Coder removes the workspace daemon token and record, but does not delete the underlying compute resource.
+- **Manual workspace daemon management**
 
-  Administrators are responsible for deploying and maintaining agents on external resources.
+  Administrators are responsible for deploying and maintaining workspace daemons on external resources.
 - **Limited UI indicators**
 
   External workspaces are marked in the UI, but underlying infrastructure health is not monitored by Coder.
@@ -52,7 +52,7 @@ Use external workspaces if:
 - You have compute resources provisioned outside of Coder’s Terraform flows.
 - You want to connect specialized or legacy systems to your Coder deployment.
 - You are migrating incrementally to Coder and need hybrid support.
-- You need finer control over how and where agents run, while still benefiting from Coder’s workspace experience.
+- You need finer control over how and where workspace daemons run, while still benefiting from Coder’s workspace experience.
 
 ## How to use it?
 
@@ -70,7 +70,7 @@ You can create and manage external workspaces using either the **CLI** or the **
    ```
 
    - Validates that the template includes a `coder_external_agent` resource.
-   - Once created, the workspace is registered in Coder but marked as requiring an external agent.
+   - Once created, the workspace is registered in Coder but marked as requiring an external workspace daemon.
 
 2. **List external workspaces**
 
@@ -85,7 +85,7 @@ You can create and manage external workspaces using either the **CLI** or the **
    hello-world      externally-managed-workspace Started  true     15m         happy_mendel9    false
    ```
 
-3. **Retrieve agent connection instructions**
+3. **Retrieve workspace daemon connection instructions**
 
    Use this command to query the script you must run on the external machine:
 
@@ -96,7 +96,7 @@ You can create and manage external workspaces using either the **CLI** or the **
    Example:
 
    ```bash
-   Please run the following command to attach external agent to the workspace hello-world:
+   Please run the following command to attach external workspace daemon to the workspace hello-world:
 
    curl -fsSL "https://<DEPLOYMENT_URL>/api/v2/init-script/linux/amd64" | CODER_AGENT_TOKEN="<token>" sh
    ```
@@ -121,10 +121,10 @@ You can create and manage external workspaces using either the **CLI** or the **
 
 1. Import the external workspace template (see prerequisites).
 2. In the Coder UI, go to **Workspaces → New workspace** and select the imported template.
-3. Once the workspace is created, Coder will display **connection details** with the command users need to run on the external machine to start the agent.
+3. Once the workspace is created, Coder will display **connection details** with the command users need to run on the external machine to start the workspace daemon.
 4. The workspace will appear in the dashboard, but with the following differences:
    - **Start**, **Stop**, and **Restart** actions are disabled.
-   - Users are provided with instructions for launching the agent manually on the external machine.
+   - Users are provided with instructions for launching the workspace daemon manually on the external machine.
 
 ![External Workspace View](../../../images/admin/templates/external-workspace.png)
 

docs/admin/templates/managing-templates/image-management.md

@@ -23,7 +23,7 @@ dependencies to work in your network and work with Coder. Here are some things
 to consider:
 
 - `curl`, `wget`, or `busybox` is required to download and run
-  [the agent](https://github.com/coder/coder/blob/main/provisionersdk/scripts/bootstrap_linux.sh)
+  [the workspace daemon](https://github.com/coder/coder/blob/main/provisionersdk/scripts/bootstrap_linux.sh)
 - `git` is recommended so developers can clone repositories
 - If the Coder server is using a certificate from an internal certificate
   authority (CA), you'll need to add or mount these into your image

docs/admin/templates/open-in-coder.md

@@ -31,7 +31,7 @@ data "coder_external_auth" "github" {
     id = "primary-github"
 }
 
-resource "coder_agent" "dev" {
+resource "coder_workspace_daemon" "dev" {
     # ...
     dir = "~/coder"
     startup_script =<<EOF
@@ -73,7 +73,7 @@ locals {
     folder_name = try(element(split("/", data.coder_parameter.git_repo.value), length(split("/", data.coder_parameter.git_repo.value)) - 1), "")
 }
 
-resource "coder_agent" "dev" {
+resource "coder_workspace_daemon" "dev" {
     # ...
     dir = "~/${local.folder_name}"
     startup_script =<<EOF

docs/admin/templates/startup-coordination/example.md

@@ -90,13 +90,13 @@ resource "docker_container" "workspace" {
   count = data.coder_workspace.me.start_count
   image = "codercom/enterprise-base:ubuntu"
   name = "coder-${data.coder_workspace_owner.me.name}-${lower(data.coder_workspace.me.name)}"
-  entrypoint = ["sh", "-c", coder_agent.main.init_script]
+  entrypoint = ["sh", "-c", coder_workspace_daemon.main.init_script]
   env        = [
-    "CODER_AGENT_TOKEN=${coder_agent.main.token}",
+    "CODER_AGENT_TOKEN=${coder_workspace_daemon.main.token}",
     ]
 }
 
-resource "coder_agent" "main" {
+resource "coder_workspace_daemon" "main" {
   arch           = data.coder_provisioner.me.arch
   os             = "linux"
 }
@@ -105,13 +105,13 @@ module "git-clone" {
   count             = data.coder_workspace.me.start_count
   source            = "registry.coder.com/coder/git-clone/coder"
   version           = "1.2.3"
-  agent_id          = coder_agent.main.id
+  agent_id          = coder_workspace_daemon.main.id
   url               = "https://github.com/miguelgrinberg/microblog"
 }
 
 resource "coder_script" "setup" {
   count              = data.coder_workspace.me.start_count
-  agent_id           = coder_agent.main.id
+  agent_id           = coder_workspace_daemon.main.id
   display_name       = "Installing Dependencies"
   run_on_start       = true
   script             = <<EOT
@@ -148,14 +148,14 @@ resource "docker_container" "workspace" {
   count = data.coder_workspace.me.start_count
   image = "codercom/enterprise-base:ubuntu"
   name = "coder-${data.coder_workspace_owner.me.name}-${lower(data.coder_workspace.me.name)}"
-  entrypoint = ["sh", "-c", coder_agent.main.init_script]
+  entrypoint = ["sh", "-c", coder_workspace_daemon.main.init_script]
   env        = [
-    "CODER_AGENT_TOKEN=${coder_agent.main.token}",
+    "CODER_AGENT_TOKEN=${coder_workspace_daemon.main.token}",
     "CODER_AGENT_SOCKET_SERVER_ENABLED=true"
     ]
 }
 
-resource "coder_agent" "main" {
+resource "coder_workspace_daemon" "main" {
   arch           = data.coder_provisioner.me.arch
   os             = "linux"
 }
@@ -164,7 +164,7 @@ module "git-clone" {
   count             = data.coder_workspace.me.start_count
   source            = "registry.coder.com/coder/git-clone/coder"
   version           = "1.2.3"
-  agent_id          = coder_agent.main.id
+  agent_id          = coder_workspace_daemon.main.id
   url               = "https://github.com/miguelgrinberg/microblog/"
   post_clone_script = <<-EOT
     coder exp sync start git-clone && coder exp sync complete git-clone
@@ -173,7 +173,7 @@ module "git-clone" {
 
 resource "coder_script" "apt-install" {
   count              = data.coder_workspace.me.start_count
-  agent_id           = coder_agent.main.id
+  agent_id           = coder_workspace_daemon.main.id
   display_name       = "Installing APT Dependencies"
   run_on_start       = true
   script             = <<EOT
@@ -187,7 +187,7 @@ resource "coder_script" "apt-install" {
 
 resource "coder_script" "pip-install" {
   count              = data.coder_workspace.me.start_count
-  agent_id           = coder_agent.main.id
+  agent_id           = coder_workspace_daemon.main.id
   display_name       = "Installing Python Dependencies"
   run_on_start       = true
   script             = <<EOT
@@ -205,7 +205,7 @@ resource "coder_script" "pip-install" {
 
 A short summary of the changes:
 
-- We've added `CODER_AGENT_SOCKET_SERVER_ENABLED=true` to the environment variables of the Docker container in which the Coder agent runs.
+- We've added `CODER_AGENT_SOCKET_SERVER_ENABLED=true` to the environment variables of the Docker container in which the workspace daemon runs.
 - We've broken the monolithic "setup" script into two separate scripts: one for the `apt` commands, and one for the `pip` commands.
   - In each script, we've added a `coder exp sync start $SCRIPT_NAME` command to mark the startup script as started.
   - We've also added an exit trap to ensure that we mark the startup scripts as completed. Without this, the `coder exp sync wait` command would eventually time out.

docs/admin/templates/startup-coordination/index.md

@@ -26,13 +26,13 @@ The goal of startup script coordination is to provide a single reliable source o
 
 To start using workspace startup coordination, follow these steps:
 
-1. Set the environment variable `CODER_AGENT_SOCKET_SERVER_ENABLED=true` in your template to enable the agent socket server. The environment variable *must* be readable to the agent process. For example, in a template using the `kreuzwerker/docker` provider:
+1. Set the environment variable `CODER_AGENT_SOCKET_SERVER_ENABLED=true` in your template to enable the workspace daemon socket server. The environment variable *must* be readable to the workspace daemon process. For example, in a template using the `kreuzwerker/docker` provider:
 
   ```terraform
   resource "docker_container" "workspace" {
     image = "codercom/enterprise-base:ubuntu"
     env = [
-      "CODER_AGENT_TOKEN=${coder_agent.main.token}",
+      "CODER_AGENT_TOKEN=${coder_workspace_daemon.main.token}",
       "CODER_AGENT_SOCKET_SERVER_ENABLED=true",
     ]
   }

docs/admin/templates/startup-coordination/troubleshooting.md

@@ -35,7 +35,7 @@ Status: completed
 Ready: true
 ```
 
-If the unit is not known to the agent, you will see output similar to the below:
+If the unit is not known to the workspace daemon, you will see output similar to the below:
 
 ```bash
 # coder exp sync status doesnotexist
@@ -51,19 +51,19 @@ No dependencies found
 
 ### Socket not enabled
 
-If the Coder Agent Socket Server is not enabled, you will see an error message similar to the below when running `coder exp sync ping`:
+If the workspace daemon socket server is not enabled, you will see an error message similar to the below when running `coder exp sync ping`:
 
 ```bash
 error: connect to agent socket: connect to socket: dial unix /tmp/coder-agent.sock: connect: no such file or directory
 ```
 
-Verify `CODER_AGENT_SOCKET_SERVER_ENABLED=true` is set in the Coder agent's environment:
+Verify `CODER_AGENT_SOCKET_SERVER_ENABLED=true` is set in the workspace daemon's environment:
 
 ```bash
 tr '\0' '\n' < /proc/$(pidof -s coder)/environ | grep CODER_AGENT_SOCKET_SERVER_ENABLED
 ```
 
-If the output of the above command is empty, review your template and ensure that the environment variable is set such that it is readable by the Coder agent process. Setting it on the `coder_agent` resource directly is **not** sufficient.
+If the output of the above command is empty, review your template and ensure that the environment variable is set such that it is readable by the workspace daemon process. Setting it on the `coder_workspace_daemon` resource directly is **not** sufficient.
 
 ## Workspace startup script hangs
 

docs/admin/templates/startup-coordination/usage.md

@@ -3,7 +3,7 @@
 > [!NOTE]
 > This feature is experimental and may change without notice in future releases.
 
-Startup coordination is built around the concept of **units**. You declare units in your Coder workspace template using the `coder exp sync` command in `coder_script` resources. When the Coder agent starts, it keeps an in-memory directed acyclic graph (DAG) of all units of which it is aware. When you need to synchronize with another unit, you can use `coder exp sync start $UNIT_NAME` to block until all dependencies of that unit have been marked complete.
+Startup coordination is built around the concept of **units**. You declare units in your Coder workspace template using the `coder exp sync` command in `coder_script` resources. When the workspace daemon starts, it keeps an in-memory directed acyclic graph (DAG) of all units of which it is aware. When you need to synchronize with another unit, you can use `coder exp sync start $UNIT_NAME` to block until all dependencies of that unit have been marked complete.
 
 ## What is a unit?
 
@@ -22,13 +22,13 @@ task.
 
 To use startup dependencies in your templates, you must:
 
-- Enable the Coder Agent Socket Server.
+- Enable the workspace daemon socket server.
 - Modify your workspace startup scripts to run in parallel and declare dependencies as required using `coder exp sync`.
 
-### Enable the Coder Agent Socket Server
+### Enable the workspace daemon socket server
 
-The agent socket server provides the communication layer for startup
-coordination. To enable it, set `CODER_AGENT_SOCKET_SERVER_ENABLED=true` in the environment in which the agent is running.
+The workspace daemon socket server provides the communication layer for startup
+coordination. To enable it, set `CODER_AGENT_SOCKET_SERVER_ENABLED=true` in the environment in which the workspace daemon is running.
 The exact method for doing this depends on your infrastructure platform:
 
 <div class="tabs">
@@ -45,7 +45,7 @@ resource "docker_container" "workspace" {
     "CODER_AGENT_SOCKET_SERVER_ENABLED=true"
   ]
 
-  command = ["sh", "-c", coder_agent.main.init_script]
+  command = ["sh", "-c", coder_workspace_daemon.main.init_script]
 }
 ```
 
@@ -64,7 +64,7 @@ resource "kubernetes_pod" "main" {
     container {
       name    = "dev"
       image   = "codercom/enterprise-base:ubuntu"
-      command = ["sh", "-c", coder_agent.main.init_script]
+      command = ["sh", "-c", coder_workspace_daemon.main.init_script]
 
       env {
         name  = "CODER_AGENT_SOCKET_SERVER_ENABLED"
@@ -236,7 +236,7 @@ resource "coder_script" "ide_setup" {
 
 ### Avoid circular dependencies
 
-The Coder Agent detects and rejects circular dependencies, but they indicate a design problem:
+The workspace daemon detects and rejects circular dependencies, but they indicate a design problem:
 
 ```bash
 # This will fail

docs/admin/templates/troubleshooting.md

@@ -1,13 +1,13 @@
 # Troubleshooting templates
 
 Occasionally, you may run into scenarios where a workspace is created, but the
-agent is either not connected or the
+workspace daemon is either not connected or the
 [startup script](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent#startup_script-1)
 has failed or timed out.
 
-## Agent connection issues
+## Workspace daemon connection issues
 
-If the agent is not connected, it means the agent or
+If the workspace daemon is not connected, it means the workspace daemon or
 [init script](https://github.com/coder/coder/tree/main/provisionersdk/scripts)
 has failed on the resource.
 
@@ -22,12 +22,12 @@ practices:
 - Ensure the resource has `curl` installed (alternatively, `wget` or `busybox`)
 - Ensure the resource can `curl` your Coder
   [access URL](../../admin/setup/index.md#access-url)
-- Manually connect to the resource and check the agent logs (e.g.,
+- Manually connect to the resource and check the workspace daemon logs (e.g.,
   `kubectl exec`, `docker exec` or AWS console)
-  - The Coder agent logs are typically stored in `/tmp/coder-agent.log`
-  - The Coder agent startup script logs are typically stored in
+  - The workspace daemon logs are typically stored in `/tmp/coder-agent.log`
+  - The workspace daemon startup script logs are typically stored in
     `/tmp/coder-startup-script.log`
-  - The Coder agent shutdown script logs are typically stored in
+  - The workspace daemon shutdown script logs are typically stored in
     `/tmp/coder-shutdown-script.log`
 - This can also happen if the websockets are not being forwarded correctly when
   running Coder behind a reverse proxy.

docs/ai-coder/agent-boundaries/index.md

@@ -71,7 +71,7 @@ filesystem:
 
 ```tf
 resource "coder_script" "boundary_config_setup" {
-  agent_id     = coder_agent.dev.id
+  agent_id     = coder_workspace_daemon.dev.id
   display_name = "Boundary Setup Configuration"
   run_on_start = true
 

docs/ai-coder/ai-bridge/clients/claude-code.md

@@ -15,7 +15,7 @@ Template admins can pre-configure Claude Code for a seamless experience. Admins
 module "claude-code" {
   source          = "registry.coder.com/coder/claude-code/coder"
   version         = "4.7.3"
-  agent_id        = coder_agent.main.id
+  agent_id        = coder_workspace_daemon.main.id
   workdir         = "/path/to/project"  # Set to your project directory
   enable_aibridge = true
 }
@@ -36,7 +36,7 @@ data "coder_task" "me" {}
 module "claude-code" {
   source         = "registry.coder.com/coder/claude-code/coder"
   version        = "4.7.3"
-  agent_id       = coder_agent.main.id
+  agent_id       = coder_workspace_daemon.main.id
   workdir        = "/path/to/project"  # Set to your project directory
   ai_prompt      = data.coder_task.me.prompt
 

docs/ai-coder/ai-bridge/clients/codex.md

@@ -33,7 +33,7 @@ If configuring within a Coder workspace, you can also use the [Codex CLI](https:
 module "codex" {
   source          = "registry.coder.com/coder-labs/codex/coder"
   version         = "~> 4.1"
-  agent_id        = coder_agent.main.id
+  agent_id        = coder_workspace_daemon.main.id
   workdir         = "/path/to/project"  # Set to your project directory
   enable_aibridge = true
 }

docs/ai-coder/ai-bridge/clients/index.md

@@ -84,7 +84,7 @@ data "coder_workspace_owner" "me" {}
 
 data "coder_workspace" "me" {}
 
-resource "coder_agent" "dev" {
+resource "coder_workspace_daemon" "dev" {
     arch = "amd64"
     os   = "linux"
     dir  = local.repo_dir

docs/ai-coder/ai-bridge/clients/mux.md

@@ -59,7 +59,7 @@ data "coder_workspace" "me" {}
 
 data "coder_workspace_owner" "me" {}
 
-resource "coder_agent" "main" {
+resource "coder_workspace_daemon" "main" {
   # ... other agent configuration
   env = {
     OPENAI_API_KEY     = data.coder_workspace_owner.me.session_token
@@ -72,7 +72,7 @@ resource "coder_agent" "main" {
 module "mux" {
   source   = "registry.coder.com/coder/mux/coder"
   version  = "~> 1.0" # See the module page for the latest version.
-  agent_id = coder_agent.main.id
+  agent_id = coder_workspace_daemon.main.id
 }
 ```
 

docs/ai-coder/github-to-tasks.md

@@ -108,7 +108,7 @@ data "coder_external_auth" "github" {
   id = "github" # Must match your CODER_EXTERNAL_AUTH_0_ID
 }
 
-resource "coder_agent" "dev" {
+resource "coder_workspace_daemon" "dev" {
   # ... other config ...
   env = {
     GITHUB_TOKEN = data.coder_external_auth.github.access_token

docs/ai-coder/tasks-core-principles.md

@@ -82,7 +82,7 @@ resource "coder_ai_task" "task" {
 module "claude-code" {
   source   = "registry.coder.com/coder/claude-code/coder"
   version  = "4.0.0"
-  agent_id = coder_agent.example.id
+  agent_id = coder_workspace_daemon.example.id
   workdir  = "/home/coder/project"
 
   claude_api_key = var.anthropic_api_key

docs/ai-coder/tasks-migration.md

@@ -76,7 +76,7 @@ terraform {
 
 data "coder_workspace" "me" {}
 
-resource "coder_agent" "main" { ... }
+resource "coder_workspace_daemon" "main" { ... }
 
 # The prompt is passed in via the specifically named "AI Prompt" parameter.
 data "coder_parameter" "ai_prompt" {
@@ -93,7 +93,7 @@ resource "coder_app" "ai_agent" {
 # Assuming that the below script runs `coder/agentapi` with the prompt
 # defined in ARG_AI_PROMPT
 resource "coder_script" "agentapi" {
-  agent_id     = coder_agent.main.id
+  agent_id     = coder_workspace_daemon.main.id
   run_on_start = true
   script       = <<EOT
     #!/usr/bin/env bash
@@ -136,7 +136,7 @@ data "coder_workspace" "me" {}
 # The prompt is now available in the coder_task data source.
 data "coder_task" "me" {}
 
-resource "coder_agent" "main" { ... }
+resource "coder_workspace_daemon" "main" { ... }
 
 # This coder_app is the interface to the Coder Task.
 # This is assumed to be a running instance of coder/agentapi (for instance, started via `coder_script`).
@@ -147,7 +147,7 @@ resource "coder_app" "ai_agent" {
 # Assuming that the below script runs `coder/agentapi` with the prompt
 # defined in ARG_AI_PROMPT
 resource "coder_script" "agentapi" {
-  agent_id     = coder_agent.main.id
+  agent_id     = coder_workspace_daemon.main.id
   run_on_start = true
   script       = <<EOT
     #!/usr/bin/env bash

docs/ai-coder/tasks.md

@@ -80,7 +80,7 @@ resource "coder_ai_task" "task" {
 module "claude-code" {
   source   = "registry.coder.com/coder/claude-code/coder"
   version  = "4.0.0"
-  agent_id = coder_agent.example.id
+  agent_id = coder_workspace_daemon.example.id
   workdir  = "/home/coder/project"
 
   claude_api_key = var.anthropic_api_key

docs/install/registry-mirror-artifactory.md

@@ -84,14 +84,14 @@ Update your Coder templates to use Artifactory instead of the public registry:
 module "code-server" {
   source   = "registry.coder.com/coder/code-server/coder"
   version  = "1.4.2"
-  agent_id = coder_agent.main.id
+  agent_id = coder_workspace_daemon.main.id
 }
 
 # After: Through Artifactory mirror
 module "code-server" {
   source   = "https://<your-artifactory-host>/coder/code-server/coder"
   version  = "1.4.2"
-  agent_id = coder_agent.main.id
+  agent_id = coder_workspace_daemon.main.id
 }
 ```
 

docs/install/releases/esr-2.24-2.29-upgrade.md

@@ -62,7 +62,7 @@ Performance, particularly at scale, improved across nearly every system layer.
 Database queries were optimized, several new indexes were added, and expensive
 migrations—such as migration 371—were reworked to complete faster on large
 deployments. Caching was introduced for Terraform installer files and
-workspace/agent lookups, reducing repeated calls. Notification performance
+workspace/workspace daemon lookups, reducing repeated calls. Notification performance
 improved through more efficient connection pooling. These changes collectively
 enable deployments with hundreds or thousands of workspaces to operate more
 smoothly and with lower resource contention.
@@ -101,9 +101,9 @@ require other manual effort to address:
 | CLI session tokens stored in plaintext file                        | CLI session tokens stored in OS keyring (macOS/Windows)                                               | Update scripts, automation, or SSO flows that read/modify the token file, or use `--use-keyring=false`. See [Sessions & API Tokens](https://coder.com/docs/admin/users/sessions-tokens) and [`coder login` CLI reference](https://coder.com/docs/reference/cli/login).          |
 | `task_app_id` field available in `codersdk.WorkspaceBuild`         | `task_app_id` removed from `codersdk.WorkspaceBuild`                                                  | Migrate integrations to use `Task.WorkspaceAppID` instead. See [REST API reference](https://coder.com/docs/reference/api).                                                                                                                                                      |
 | OIDC session handling more permissive                              | Sessions expire when access tokens expire (typically 1 hour) unless refresh tokens are configured     | Add `offline_access` to `CODER_OIDC_SCOPES` (e.g., `openid,profile,email,offline_access`); Google requires `CODER_OIDC_AUTH_URL_PARAMS='{"access_type":"offline","prompt":"consent"}'`. See [OIDC Refresh Tokens](https://coder.com/docs/admin/users/oidc-auth/refresh-tokens). |
-| Devcontainer agent selection is random when multiple agents exist  | Devcontainer agent selection requires explicit choice                                                 | Update automated workflows to explicitly specify agent selection. See [Dev Containers Integration](https://coder.com/docs/user-guides/devcontainers) and [Configure a template for dev containers](https://coder.com/docs/admin/templates/extending-templates/devcontainers).   |
+| Devcontainer workspace daemon selection is random when multiple workspace daemons exist  | Devcontainer workspace daemon selection requires explicit choice                                                 | Update automated workflows to explicitly specify workspace daemon selection. See [Dev Containers Integration](https://coder.com/docs/user-guides/devcontainers) and [Configure a template for dev containers](https://coder.com/docs/admin/templates/extending-templates/devcontainers).   |
 | Terraform execution uses clean directories per build               | Terraform workflows use persistent or cached directories when enabled                                 | Update templates that rely on clean execution directories or per-build isolation. See [External Provisioners](https://coder.com/docs/admin/provisioners) and [Template Dependencies](https://coder.com/docs/admin/templates/managing-templates/dependencies).                   |
-| Agent and task lifecycle behaviors more permissive                 | Agent and task lifecycle behaviors enforce stricter permission checks, readiness gating, and ordering | Review workflows for compatibility with stricter readiness and permission requirements. See [Workspace Lifecycle](https://coder.com/docs/user-guides/workspace-lifecycle) and [Extending Templates](https://coder.com/docs/admin/templates/extending-templates).                |
+| Workspace daemon and task lifecycle behaviors more permissive                 | Workspace daemon and task lifecycle behaviors enforce stricter permission checks, readiness gating, and ordering | Review workflows for compatibility with stricter readiness and permission requirements. See [Workspace Lifecycle](https://coder.com/docs/user-guides/workspace-lifecycle) and [Extending Templates](https://coder.com/docs/admin/templates/extending-templates).                |
 
 ## Upgrading
 
@@ -116,7 +116,7 @@ The following are recommendations by the Coder team when performing the upgrade:
 - **Audit scripts or tools that rely on the CLI token file:** Since 2.29 uses
   the OS keyring for session tokens on macOS and Windows, update any tooling
   that reads the plaintext token file or plan to use `--use-keyring=false`
-- **Review templates using devcontainers or Terraform:** Explicit agent
+- **Review templates using devcontainers or Terraform:** Explicit workspace daemon
   selection, optional persistent/cached Terraform directories, and updated
   metadata handling mean template authors should retest builds and startup
   behavior
@@ -133,8 +133,8 @@ The following are recommendations by the Coder team when performing the upgrade:
 - **Validate workspace lifecycle automation:** Since updates now require
   stopping the workspace first, confirm that automated update jobs, scripts, or
   scheduled tasks still function correctly in this new model
-- **Retest agent and task automation built on early experimental features:**
-  Updates to agent readiness, permission checks, and lifecycle ordering may
+- **Retest workspace daemon and task automation built on early experimental features:**
+  Updates to workspace daemon readiness, permission checks, and lifecycle ordering may
   affect workflows developed against 2.24’s looser behaviors
 - **Monitor workspace, template, and Terraform build performance:** New caching,
   indexes, and DB optimizations may change build times; observing performance

docs/support/support-bundle.md

@@ -11,7 +11,7 @@ A support bundle is an archive containing a snapshot of information about your
 Coder deployment.
 
 It contains information about the workspace, the template it uses, running
-agents in the workspace, and other detailed information useful for
+workspace daemons, and other detailed information useful for
 troubleshooting.
 
 It is primarily intended for troubleshooting connectivity issues to workspaces,
@@ -29,21 +29,21 @@ A brief overview of all files contained in the bundle is provided below:
 
 | Filename                          | Description                                                                                                |
 |-----------------------------------|------------------------------------------------------------------------------------------------------------|
-| `agent/agent.json`                | The agent used to connect to the workspace with environment variables stripped.                            |
-| `agent/agent_magicsock.html`      | The contents of the HTTP debug endpoint of the agent's Tailscale Wireguard connection.                     |
+| `agent/agent.json`                | The workspace daemon used to connect to the workspace with environment variables stripped.                 |
+| `agent/agent_magicsock.html`      | The contents of the HTTP debug endpoint of the workspace daemon's Tailscale Wireguard connection.          |
 | `agent/client_magicsock.html`     | The contents of the HTTP debug endpoint of the client's Tailscale Wireguard connection.                    |
-| `agent/listening_ports.json`      | The listening ports detected by the selected agent running in the workspace.                               |
-| `agent/logs.txt`                  | The logs of the selected agent running in the workspace.                                                   |
-| `agent/manifest.json`             | The manifest of the selected agent with environment variables stripped.                                    |
-| `agent/startup_logs.txt`          | Startup logs of the workspace agent.                                                                       |
-| `agent/prometheus.txt`            | The contents of the agent's Prometheus endpoint.                                                           |
+| `agent/listening_ports.json`      | The listening ports detected by the selected workspace daemon running in the workspace.                    |
+| `agent/logs.txt`                  | The logs of the selected workspace daemon running in the workspace.                                        |
+| `agent/manifest.json`             | The manifest of the selected workspace daemon with environment variables stripped.                          |
+| `agent/startup_logs.txt`          | Startup logs of the workspace daemon.                                                                      |
+| `agent/prometheus.txt`            | The contents of the workspace daemon's Prometheus endpoint.                                                |
 | `cli_logs.txt`                    | Logs from running the `coder support bundle` command.                                                      |
 | `deployment/buildinfo.json`       | Coder version and build information.                                                                       |
 | `deployment/config.json`          | Deployment [configuration](../reference/api/general.md#get-deployment-config), with secret values removed. |
 | `deployment/experiments.json`     | Any [experiments](../reference/cli/server.md#--experiments) currently enabled for the deployment.          |
 | `deployment/health.json`          | A snapshot of the [health status](../admin/monitoring/health-check.md) of the deployment.                  |
 | `logs.txt`                        | Logs from the `codersdk.Client` used to generate the bundle.                                               |
-| `network/connection_info.json`    | Information used by workspace agents used to connect to Coder (DERP map etc.)                              |
+| `network/connection_info.json`    | Information used by workspace daemons to connect to Coder (DERP map etc.)                                  |
 | `network/coordinator_debug.html`  | Peers currently connected to each Coder instance and the tunnels established between peers.                |
 | `network/netcheck.json`           | Results of running `coder netcheck` locally.                                                               |
 | `network/tailnet_debug.html`      | Tailnet coordinators, their heartbeat ages, connected peers, and tunnels.                                  |

docs/tutorials/best-practices/scale-coder.md

@@ -71,15 +71,15 @@ Edit your Helm `values.yaml` to capture metrics from Coder Server and external p
    CODER_PROMETHEUS_COLLECT_DB_METRICS=true
    ```
 
-1. For a high scale deployment, configure agent stats to avoid large cardinality or disable them:
+1. For a high scale deployment, configure workspace daemon stats to avoid large cardinality or disable them:
 
-   - Configure agent stats:
+   - Configure workspace daemon stats:
 
      ```yaml
      CODER_PROMETHEUS_AGGREGATE_AGENT_STATS_BY=agent_name
      ```
 
-   - Disable agent stats:
+   - Disable workspace daemon stats:
 
      ```yaml
      CODER_PROMETHEUS_COLLECT_AGENT_STATS=false

docs/tutorials/best-practices/security-best-practices.md

@@ -102,7 +102,7 @@ vulnerable.
 Coder session tokens and API keys are salted and hashed, so a read-only
 compromise of the database is unlikely to allow an attacker to log into Coder.
 However, the database contains the Terraform state for all workspaces, OIDC
-tokens, and agent tokens, so it is possible that a read-only attack could enable
+tokens, and workspace daemon tokens, so it is possible that a read-only attack could enable
 lateral movement to other systems.
 
 A successful attack that modifies database state could be escalated to a full
@@ -289,7 +289,7 @@ code via the
 
 Furthermore, Coder templates are designed to provision compute resources in one
 or more clusters/clouds, and template authors are generally in full control over
-code and scripts executed by the Coder agent in those compute resources.
+code and scripts executed by the workspace daemon in those compute resources.
 
 This means that template admins have remote code execution privileges for any
 provisioner daemons in their organization and within any cluster/cloud those

docs/tutorials/cloning-git-repositories.md

@@ -33,7 +33,7 @@ Terraform configuration.
 module "git-clone" {
   source   = "registry.coder.com/modules/git-clone/coder"
   version  = "1.0.12"
-  agent_id = coder_agent.example.id
+  agent_id = coder_workspace_daemon.example.id
   url      = "https://github.com/coder/coder"
 }
 ```
@@ -57,7 +57,7 @@ data "coder_parameter" "git_repo" {
 module "git-clone" {
   source   = "registry.coder.com/modules/git-clone/coder"
   version  = "1.0.12"
-  agent_id = coder_agent.example.id
+  agent_id = coder_workspace_daemon.example.id
   url      = data.coder_parameter.git_repo.value
 }
 ```

docs/tutorials/faqs.md

@@ -104,7 +104,7 @@ properly.
 
 The visibility of Coder apps is configurable in the template. To change the
 default (shows all), add this block inside the
-[`coder_agent`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent)
+[`coder_workspace_daemon`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent)
 of a template and configure as needed:
 
 ```tf
@@ -154,10 +154,10 @@ resource "coder_app" "code-server" {
 ## I installed Coder and created a workspace but the icons do not load
 
 An important concept to understand is that Coder creates workspaces which have
-an agent that must be able to reach the `coder server`.
+a workspace daemon that must be able to reach the `coder server`.
 
 If the [`CODER_ACCESS_URL`](../admin/setup/index.md#access-url) is not
-accessible from a workspace, the workspace may build, but the agent cannot reach
+accessible from a workspace, the workspace may build, but the workspace daemon cannot reach
 Coder, and thus the missing icons. e.g., Terminal, IDEs, Apps.
 
 By default, `coder server` automatically creates an Internet-accessible
@@ -471,7 +471,7 @@ like code-server when creating the workspace.
     # code-server
     resource "coder_app" "code-server" {
     count         = data.coder_parameter.code_server.value ? 1 : 0
-    agent_id      = coder_agent.coder.id
+    agent_id      = coder_workspace_daemon.coder.id
     slug          = "code-server"
     display_name  = "code-server"
     icon          = "/icon/code.svg"
@@ -542,7 +542,7 @@ block list, which includes `scp`, `rsync`, `ftp`, and `nc`.
 resource "docker_container" "workspace" {
   ...
   env = [
-    "CODER_AGENT_TOKEN=${coder_agent.main.token}",
+    "CODER_AGENT_TOKEN=${coder_workspace_daemon.main.token}",
     "CODER_AGENT_BLOCK_FILE_TRANSFER=true",
     ...
   ]

docs/tutorials/template-from-scratch.md

@@ -118,21 +118,21 @@ started or stopped. We'll use this information in later steps to:
 - Set some environment variables based on the workspace owner.
 - Manage ephemeral and persistent storage.
 
-## 3. coder_agent
+## 3. coder_workspace_daemon
 
 All templates need to create and run a
-[Coder agent](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent).
-This lets developers connect to their workspaces. The `coder_agent` resource
+[workspace daemon](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent).
+This lets developers connect to their workspaces. The `coder_workspace_daemon` resource
 runs inside the compute aspect of your workspace, typically a VM or container.
 In our case, it will run in Docker.
 
-You do not need to have any open ports on the compute aspect, but the agent
-needs `curl` access to the Coder server.
+You do not need to have any open ports on the compute aspect, but the workspace
+daemon needs `curl` access to the Coder server.
 
-Add this snippet after the last closing `}` in `main.tf` to create the agent:
+Add this snippet after the last closing `}` in `main.tf` to create the workspace daemon:
 
 ```tf
-resource "coder_agent" "main" {
+resource "coder_workspace_daemon" "main" {
   arch                   = data.coder_provisioner.me.arch
   os                     = "linux"
   startup_script         = <<-EOT
@@ -169,11 +169,11 @@ resource "coder_agent" "main" {
 ```
 
 Because Docker is running locally in the Coder server, there is no need to
-authenticate `coder_agent`. But if your `coder_agent` is running on a remote
+authenticate `coder_workspace_daemon`. But if your `coder_workspace_daemon` is running on a remote
 host, your template will need
 [authentication credentials](../admin/external-auth/index.md).
 
-This template's agent also runs a startup script, sets environment variables,
+This template's workspace daemon also runs a startup script, sets environment variables,
 and provides metadata.
 
 - [`startup script`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/agent#startup_script)
@@ -216,7 +216,7 @@ See [web IDEs](../user-guides/workspace-access/web-ides.md) for more examples:
 
 ```tf
 resource "coder_app" "code-server" {
-  agent_id     = coder_agent.main.id
+  agent_id     = coder_workspace_daemon.main.id
   slug         = "code-server"
   display_name = "code-server"
   url          = "http://localhost:13337/?folder=/home/${local.username}"
@@ -237,7 +237,7 @@ to wikis or cloud consoles:
 
 ```tf
 resource "coder_app" "coder-server-doc" {
-  agent_id     = coder_agent.main.id
+  agent_id     = coder_workspace_daemon.main.id
   icon         = "/emojis/1f4dd.png"
   slug         = "getting-started"
   url          = "https://coder.com/docs/code-server"
@@ -310,9 +310,9 @@ resource "docker_container" "workspace" {
   # Hostname makes the shell more user friendly: coder@my-workspace:~$
   hostname = data.coder_workspace.me.name
   # Use the docker gateway if the access URL is 127.0.0.1
-  entrypoint = ["sh", "-c", replace(coder_agent.main.init_script, "/localhost|127\\.0\\.0\\.1/", "host.docker.internal")]
+  entrypoint = ["sh", "-c", replace(coder_workspace_daemon.main.init_script, "/localhost|127\\.0\\.0\\.1/", "host.docker.internal")]
   env = [
-    "CODER_AGENT_TOKEN=${coder_agent.main.token}",
+    "CODER_AGENT_TOKEN=${coder_workspace_daemon.main.token}",
   ]
   host {
     host = "host.docker.internal"

docs/user-guides/desktop/desktop-connect-sync.md

@@ -11,7 +11,7 @@ While active, Coder Connect will list the workspaces you own and will configure
 
 ![Coder Desktop list of workspaces](../../images/user-guides/desktop/coder-desktop-workspaces.png)
 
-To copy the `.coder` hostname of a workspace agent, select the copy icon beside it.
+To copy the `.coder` hostname of a workspace daemon, select the copy icon beside it.
 
 You can also connect to the SSH server in your workspace using any SSH client, such as OpenSSH or PuTTY:
 

docs/user-guides/devcontainers/customizing-dev-containers.md

@@ -65,9 +65,9 @@ and shown in the UI, but users must manually start it.
 > If this setting is disabled at the template level, containers won't auto-start
 > regardless of this option.
 
-## Custom agent name
+## Custom workspace daemon name
 
-Each dev container gets an agent name derived from the workspace folder path by
+Each dev container gets a name derived from the workspace folder path by
 default. You can set a custom name using the `name` option:
 
 ```json
@@ -234,7 +234,7 @@ Coder provides these environment variables automatically:
 | `CODER_WORKSPACE_NAME`              | Name of the workspace              |
 | `CODER_WORKSPACE_OWNER_NAME`        | Username of the workspace owner    |
 | `CODER_WORKSPACE_AGENT_NAME`        | Name of the dev container agent    |
-| `CODER_WORKSPACE_PARENT_AGENT_NAME` | Name of the parent workspace agent |
+| `CODER_WORKSPACE_PARENT_AGENT_NAME` | Name of the parent workspace daemon |
 | `CODER_URL`                         | URL of the Coder deployment        |
 | `CONTAINER_ID`                      | Docker container ID                |
 

docs/user-guides/devcontainers/index.md

@@ -11,7 +11,7 @@ administrators can configure
 [Envbuilder](../../admin/integrations/devcontainers/envbuilder/index.md) instead,
 which builds the workspace image itself from your dev container configuration.
 
-![Two dev containers running as sub-agents in a Coder workspace](../../images/user-guides/devcontainers/devcontainer-running.png)_Dev containers appear as sub-agents with their own apps, SSH access, and port forwarding_
+![Two dev containers running as sub-daemons in a Coder workspace](../../images/user-guides/devcontainers/devcontainer-running.png)_Dev containers appear as sub-daemons with their own apps, SSH access, and port forwarding_
 
 ## Prerequisites
 
@@ -78,7 +78,7 @@ container will build and start automatically when the workspace starts.
 
 ### Connect to your dev container
 
-Once running, your dev container appears as a sub-agent in your workspace
+Once running, your dev container appears as a sub-daemon in your workspace
 dashboard. You can connect via:
 
 - **Web terminal** in the Coder dashboard
@@ -97,27 +97,27 @@ containers within your Coder workspace.
 When a workspace with Dev Containers integration starts:
 
 1. If the template defines `coder_app`, `coder_script`, or `coder_env` resources
-   attached to the dev container, a sub-agent is pre-created with these resources.
+   attached to the dev container, a sub-daemon is pre-created with these resources.
 1. The workspace initializes the Docker environment.
 1. The integration detects repositories with dev container configurations.
 1. Detected dev containers appear in the Coder dashboard.
 1. If auto-start is configured (via `coder_devcontainer` or autostart settings),
    the integration builds and starts the dev container automatically.
-1. Coder creates a sub-agent (or updates the pre-created one) for the running
+1. Coder creates a sub-daemon (or updates the pre-created one) for the running
    container, enabling direct access.
 
 Without auto-start, users can manually start discovered dev containers from the
 dashboard.
 
-### Agent naming
+### Workspace daemon naming
 
-Each dev container gets its own agent name, derived from the workspace folder
+Each dev container gets its own name, derived from the workspace folder
 path. For example, a dev container with workspace folder `/home/coder/my-app`
-will have an agent named `my-app`.
+will have a sub-daemon named `my-app`.
 
-Agent names are sanitized to contain only lowercase alphanumeric characters and
+Sub-daemon names are sanitized to contain only lowercase alphanumeric characters and
 hyphens. You can also set a
-[custom agent name](./customizing-dev-containers.md#custom-agent-name)
+[custom workspace daemon name](./customizing-dev-containers.md#custom-workspace-daemon-name)
 in your `devcontainer.json`.
 
 ## Limitations
@@ -129,14 +129,14 @@ in your `devcontainer.json`.
 - The `forwardPorts` property in `devcontainer.json` with `host:port` syntax
   (e.g., `"db:5432"`) for Docker Compose sidecar containers is not yet
   supported. For single-container dev containers, use `coder port-forward` to
-  access ports directly on the sub-agent.
+  access ports directly on the sub-daemon.
 - Some advanced dev container features may have limited support
 
 ## Next steps
 
 - [Working with dev containers](./working-with-dev-containers.md) — SSH, IDE
   integration, and port forwarding
-- [Customizing dev containers](./customizing-dev-containers.md) — Custom agent
+- [Customizing dev containers](./customizing-dev-containers.md) — Custom workspace daemon
   names, apps, and display options
 - [Troubleshooting dev containers](./troubleshooting-dev-containers.md) —
   Diagnose common issues

docs/user-guides/devcontainers/troubleshooting-dev-containers.md

@@ -4,7 +4,7 @@
 
 If your dev container fails to start:
 
-1. Check the agent logs for error messages:
+1. Check the workspace daemon logs for error messages:
 
    - `/tmp/coder-agent.log`
    - `/tmp/coder-startup-script.log`
@@ -36,30 +36,30 @@ docker ps  # test access
 
 If you get permission errors, your user may need to be in the `docker` group.
 
-## Finding your dev container agent
+## Finding your dev container workspace daemon
 
-Use `coder show` to list all agents in your workspace, including dev container
-sub-agents:
+Use `coder show` to list all workspace daemons in your workspace, including dev container
+sub-daemons:
 
 ```console
 coder show <workspace>
 ```
 
-The agent name is derived from the workspace folder path. For details on how
-names are generated, see [Agent naming](./index.md#agent-naming).
+The name is derived from the workspace folder path. For details on how
+names are generated, see [Workspace daemon naming](./index.md#workspace-daemon-naming).
 
 ## SSH connection issues
 
 If `coder ssh <workspace>.<agent>` fails:
 
-1. Verify the agent name using `coder show <workspace>`.
+1. Verify the workspace daemon name using `coder show <workspace>`.
 1. Check that the dev container is running:
 
    ```console
    docker ps
    ```
 
-1. Check the workspace agent logs for container-related errors:
+1. Check the workspace daemon logs for container-related errors:
 
    ```console
    grep -i container /tmp/coder-agent.log
@@ -68,12 +68,12 @@ If `coder ssh <workspace>.<agent>` fails:
 ## VS Code connection issues
 
 VS Code connects to dev containers through the Coder extension. The extension
-uses the sub-agent information to route connections through the parent workspace
-agent to the dev container. If VS Code fails to connect:
+uses the sub-daemon information to route connections through the parent workspace
+daemon to the dev container. If VS Code fails to connect:
 
 1. Ensure you have the latest Coder VS Code extension.
 1. Verify the dev container is running in the Coder dashboard.
-1. Check the parent workspace agent is healthy.
+1. Check the parent workspace daemon is healthy.
 1. Try restarting the dev container from the dashboard.
 
 ## Dev container features not working
@@ -110,7 +110,7 @@ If your dev container takes a long time to start:
 
 If you continue to experience issues:
 
-1. Collect logs from `/tmp/coder-agent.log` (both workspace and container).
+1. Collect logs from `/tmp/coder-agent.log` (both workspace daemon and container).
 1. Note the exact error messages.
 1. Check [Coder GitHub issues](https://github.com/coder/coder/issues) for
    similar problems.

docs/user-guides/devcontainers/working-with-dev-containers.md

@@ -3,32 +3,32 @@
 The dev container integration appears in your Coder dashboard, providing a
 visual representation of the running environment:
 
-![Two dev containers running as sub-agents in a Coder workspace](../../images/user-guides/devcontainers/devcontainer-running.png)_Dev containers appear as sub-agents with their own apps, SSH access, and port forwarding_
+![Two dev containers running as sub-daemons in a Coder workspace](../../images/user-guides/devcontainers/devcontainer-running.png)_Dev containers appear as sub-daemons with their own apps, SSH access, and port forwarding_
 
 ## SSH access
 
-Each dev container has its own agent name, derived from the workspace folder
-(e.g., `/home/coder/my-project` becomes `my-project`). You can find agent names
+Each dev container has its own name, derived from the workspace folder
+(e.g., `/home/coder/my-project` becomes `my-project`). You can find names
 in your workspace dashboard, or see
-[Agent naming](./index.md#agent-naming) for details on how names are generated.
+[Workspace daemon naming](./index.md#workspace-daemon-naming) for details on how names are generated.
 
 ### Using the Coder CLI
 
 The simplest way to SSH into a dev container is using `coder ssh` with the
-workspace and agent name:
+workspace and workspace daemon name:
 
 ```console
 coder ssh <workspace>.<agent>
 ```
 
-For example, to connect to a dev container with agent name `my-project` in
+For example, to connect to a dev container with workspace daemon name `my-project` in
 workspace `my-workspace`:
 
 ```console
 coder ssh my-workspace.my-project
 ```
 
-To SSH into the main workspace agent instead of the dev container:
+To SSH into the main workspace daemon instead of the dev container:
 
 ```console
 coder ssh my-workspace
@@ -44,7 +44,7 @@ coder config-ssh
 ```
 
 This creates a wildcard SSH host entry that matches all your workspaces and
-their agents, including dev container sub-agents. You can then connect using:
+their workspace daemons, including dev container sub-daemons. You can then connect using:
 
 ```console
 ssh my-project.my-workspace.me.coder
@@ -69,7 +69,7 @@ in the Coder interface to execute commands directly inside the dev container.
 
 You can open your dev container directly in VS Code by:
 
-1. Selecting **Open in VS Code Desktop** from the dev container agent in the
+1. Selecting **Open in VS Code Desktop** from the dev container workspace daemon in the
    Coder web interface.
 1. Using the Coder CLI:
 
@@ -91,14 +91,14 @@ work.
 
 ## Port forwarding
 
-Since dev containers run as sub-agents, you can forward ports directly to them
+Since dev containers run as sub-daemons, you can forward ports directly to them
 using standard Coder port forwarding:
 
 ```console
 coder port-forward <workspace>.<agent> --tcp 8080
 ```
 
-For example, to forward port 8080 from a dev container with agent name
+For example, to forward port 8080 from a dev container with workspace daemon name
 `my-project`:
 
 ```console
@@ -110,8 +110,8 @@ container. Coder also automatically detects ports opened inside the container.
 
 ### Exposing ports on the parent workspace
 
-If you need to expose dev container ports through the parent workspace agent
-(rather than the sub-agent), you can use the
+If you need to expose dev container ports through the parent workspace daemon
+(rather than the sub-daemon), you can use the
 [`appPort`](https://containers.dev/implementors/json_reference/#image-specific)
 property in your `devcontainer.json`:
 
@@ -122,7 +122,7 @@ property in your `devcontainer.json`:
 ```
 
 This maps container ports to the parent workspace, which can then be forwarded
-using the main workspace agent.
+using the main workspace daemon.
 
 ## Dev container features
 

docs/user-guides/shared-workspaces.md

@@ -104,7 +104,7 @@ To allow other users to access workspace apps, configure subdomain-based access:
    ```hcl
    module "code-server" {
      source    = "registry.coder.com/coder/code-server/coder"
-     agent_id  = coder_agent.main.id
+     agent_id  = coder_workspace_daemon.main.id
      subdomain = true
      # ...
    }

docs/user-guides/workspace-access/antigravity.md

@@ -62,7 +62,7 @@ module "antigravity" {
   count    = data.coder_workspace.me.start_count
   source   = "registry.coder.com/coder/antigravity/coder"
   version  = "1.0.0"
-  agent_id = coder_agent.example.id
+  agent_id = coder_workspace_daemon.example.id
   folder   = "/home/coder/project"
 }
 ```

docs/user-guides/workspace-access/emacs-tramp.md

@@ -49,7 +49,7 @@ To fix this:
    data "coder_workspace" "me" {
    }
 
-   resource "coder_agent" "main" {
+   resource "coder_workspace_daemon" "main" {
      # ...
      env = {
        name = "CODER_WORKSPACE_NAME"

docs/user-guides/workspace-access/jetbrains/toolbox.md

@@ -39,7 +39,7 @@ Required parameters:
 
 Optional parameters:
 
-- `agent_id`: ID of the agent (only required if workspace has multiple agents)
+- `agent_id`: ID of the workspace daemon (only required if workspace has multiple workspace daemons)
 - `folder`: Specific project folder path to open
 - `ide_product_code`: Specific IDE product code (e.g., "IU" for IntelliJ IDEA Ultimate)
 - `ide_build_number`: Specific build number of the JetBrains IDE

docs/user-guides/workspace-access/port-forwarding.md

@@ -61,7 +61,7 @@ proxy the deployment, and port forwarding will work.
 There is a
 [DNS limitation](https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1)
 where each segment of hostnames must not exceed 63 characters. If your app
-name, agent name, workspace name and username exceed 63 characters in the
+name, workspace daemon name, workspace name and username exceed 63 characters in the
 hostname, port forwarding via the dashboard will not work.
 
 ### From a coder_app resource
@@ -74,7 +74,7 @@ the `subdomain` and `share` settings:
 ```tf
 # node app
 resource "coder_app" "node-react-app" {
-  agent_id  = coder_agent.dev.id
+  agent_id  = coder_workspace_daemon.dev.id
   slug      = "node-react-app"
   icon      = "https://upload.wikimedia.org/wikipedia/commons/a/a7/React-icon.svg"
   url       = "http://localhost:3000"
@@ -101,7 +101,7 @@ accessible by users outside of the Coder deployment.
 Another way to port forward in the dashboard is to use the "Open Ports" button
 to specify an arbitrary port. Coder will also detect if apps inside the
 workspace are listening on ports, and list them below the port input (this is
-only supported on Windows and Linux workspace agents).
+only supported on Windows and Linux workspace daemons).
 
 ![Port forwarding in the UI](../../images/networking/listeningports.png)
 

docs/user-guides/workspace-access/remote-desktops.md

@@ -44,7 +44,7 @@ locals {
 }
 
 resource "coder_app" "rdp-coder-desktop" {
-  agent_id     = resource.coder_agent.main.id
+  agent_id     = resource.coder_workspace_daemon.main.id
   slug         = "rdp-desktop"
   display_name = "RDP Desktop"
   url          = "coder://${local.server_name}/v0/open/ws/${data.coder_workspace.me.name}/agent/main/rdp?username=Administrator&password=coderRDP!"

docs/user-guides/workspace-access/vscode.md

@@ -101,7 +101,7 @@ Web or using the workspace's terminal.
    **Startup Script**
 
    ```tf
-   resource "coder_agent" "main" {
+   resource "coder_workspace_daemon" "main" {
      ...
      startup_script = "code-server --install-extension /vsix/GitHub.copilot.vsix"
    }

docs/user-guides/workspace-access/web-terminal.md

@@ -35,7 +35,7 @@ and feature-rich terminal experience in your browser.
 2. Click the **Terminal** button or icon
 3. The terminal will open in a new browser tab or window
 
-The terminal automatically connects to your workspace agent using an optimized
+The terminal automatically connects to your workspace daemon using an optimized
 WebSocket connection.
 
 ### Direct URL Access
@@ -46,7 +46,7 @@ You can also bookmark or share direct terminal URLs:
 https://coder.example.com/@username/workspace-name/terminal
 ```
 
-To access a specific agent in a multi-agent workspace:
+To access a specific workspace daemon in a workspace with multiple daemons:
 
 ```text
 https://coder.example.com/@username/workspace-name.agent-name/terminal
@@ -62,10 +62,10 @@ workspace:
 1. **Browser**: Renders the terminal using xterm.js
 2. **WebSocket**: Maintains a persistent, low-latency connection
 3. **Coder Server**: Routes traffic between browser and workspace
-4. **Workspace Agent**: Manages the pseudo-terminal (PTY) session
+4. **Workspace Daemon**: Manages the pseudo-terminal (PTY) session
 5. **Shell Process**: Your actual bash/zsh/fish shell
 
-The connection flow is: Browser ↔ WebSocket ↔ Coder Server ↔ Workspace Agent ↔ Shell Process
+The connection flow is: Browser ↔ WebSocket ↔ Coder Server ↔ Workspace Daemon ↔ Shell Process
 
 ### Reconnection & Persistence
 
@@ -73,7 +73,7 @@ The terminal uses reconnection tokens to maintain session state:
 
 - Each terminal session has a unique UUID
 - If the connection drops, the same token is used to reconnect
-- The workspace agent buffers output during disconnections
+- The workspace daemon buffers output during disconnections
 - Your shell session continues running even when the browser is closed
 
 ## Customization
@@ -222,7 +222,7 @@ export CTERM=xterm-256color
 If the terminal fails to connect:
 
 1. **Check workspace status**: Ensure your workspace is running
-2. **Verify agent health**: Look for agent connection warnings
+2. **Verify workspace daemon health**: Look for connection warnings
 3. **Network issues**: Check if WebSockets are blocked by your firewall/proxy
 4. **Browser console**: Open DevTools to see WebSocket error messages
 

docs/user-guides/workspace-lifecycle.md

@@ -2,7 +2,7 @@
 
 Workspaces are flexible, reproducible, and isolated units of compute. Workspaces
 are created via Terraform, managed through the Coder control plane, accessed
-through the Coder agent, then stopped and deleted again by Terraform.
+through the workspace daemon, then stopped and deleted again by Terraform.
 
 This page covers how workspaces move through this lifecycle. To learn about
 automating workspace schedules for cost control, read the
@@ -30,8 +30,8 @@ If some error occurs during the above, a workspace may fall into one of the
 following broken states:
 
 - Failed: Failure during provisioning, no resource consumption
-- Unhealthy: Resources have been provisioned, but the agent can't facilitate
-  connections
+- Unhealthy: Resources have been provisioned, but the workspace daemon can't
+  facilitate connections
 
 ## Workspace creation
 
@@ -49,17 +49,19 @@ plane. Coder takes this and uses [Terraform](https://www.terraform.io/) to
 provision a workspace defined by your [template](../admin/templates/index.md).
 Generally, templates define the resources and environment of a workspace.
 
-The resources that run the agent are described as _computational resources_,
-while those that don't are called _peripheral resources_. A workspace must
-contain some computational resource to run the Coder agent process.
+The resources that run the workspace daemon are described as _computational
+resources_, while those that don't are called _peripheral resources_. A
+workspace must contain some computational resource to run the workspace daemon
+process.
 
-The provisioned workspace's computational resources start the agent process,
-which opens connections to your workspace via SSH, the terminal, and IDES such
+The provisioned workspace's computational resources start the workspace daemon
+process, which opens connections to your workspace via SSH, the terminal, and
+IDES such
 as [JetBrains](./workspace-access/jetbrains/index.md) or
 [VSCode](./workspace-access/vscode.md).
 
-Once started, the Coder agent is responsible for running your workspace startup
-scripts. These may configure tools, service connections, or personalization with
+Once started, the workspace daemon is responsible for running your workspace
+startup scripts. These may configure tools, service connections, or personalization with
 [dotfiles](./workspace-dotfiles.md). For complex initialization with multiple
 dependent scripts, see
 [Workspace Startup Coordination](../admin/templates/startup-coordination/index.md).
@@ -104,18 +106,19 @@ considered cautiously as orphaning may lead to unaccounted cloud resources.
 During a workspace start or stop build, one of two errors may lead to a broken
 state. If the call to `terraform apply` fails to correctly provision resources,
 a workspace build has **failed**. If the computational resources fail to connect
-the agent, a workspace becomes **unhealthy**.
+the workspace daemon, a workspace becomes **unhealthy**.
 
 A failed workspace is most often caused by misalignment from the definition in
 your template's Terraform file and the target resources on your infrastructure.
-Unhealthy workspaces are usually caused by a misconfiguration in the agent or
-workspace startup scripts.
+Unhealthy workspaces are usually caused by a misconfiguration in the workspace
+daemon or workspace startup scripts.
 
 ## Workspace build times
 
 After a successful build, you can see a timing breakdown of the workspace
 startup process from the dashboard (starting in v2.17). We capture and display
-both time taken to provision the workspace's compute and agent startup steps.
+both time taken to provision the workspace's compute and workspace daemon startup
+steps.
 These include any
 [`coder_script`](https://registry.terraform.io/providers/coder/coder/latest/docs/resources/script)s
 such as [dotfiles](./workspace-dotfiles.md) or

docs/user-guides/workspace-management.md

@@ -65,7 +65,7 @@ The following filters are supported:
   `outdated:true`
 - `dormant` - Filters workspaces based on the dormant state, e.g `dormant:true`
 - `has-agent` - Only applicable for workspaces in "start" transition. Stopped
-  and deleted workspaces don't have agents. List of supported values
+  and deleted workspaces don't have workspace daemons. List of supported values
   `connecting|connected|timeout|disconnected`, e.g, `has-agent:connecting`
 - `id` - Workspace UUID
 - `healthy` - Only applicable for workspaces in "start" transition. `healthy:false` is an alias for `has-agent:timeout,disconnected`, `healthy:true` is an alias for `has-agent:connected`.
@@ -185,7 +185,7 @@ Coder stores macOS and Linux logs at the following locations:
 |-------------------|----------------------------------|
 | `startup_script`  | `/tmp/coder-startup-script.log`  |
 | `shutdown_script` | `/tmp/coder-shutdown-script.log` |
-| Agent             | `/tmp/coder-agent.log`           |
+| Workspace daemon  | `/tmp/coder-agent.log`           |
 
 > [!NOTE]
 > Logs are truncated once they reach 5MB in size.

docs/user-guides/workspace-scheduling.md

@@ -67,7 +67,7 @@ The following actions do **not** count as workspace activity:
 - Viewing or editing workspace settings
 - Viewing build logs or audit logs
 - Accessing ports through direct URLs without an active session
-- Background agent statistics reporting
+- Background workspace daemon statistics reporting
 
 To avoid unexpected cloud costs, close your connections, this includes IDE windows, SSH sessions, and others, when you finish using your workspace.
 

site/src/modules/resources/AgentOutdatedTooltip.tsx

@@ -30,12 +30,12 @@ export const AgentOutdatedTooltip: FC<AgentOutdatedTooltipProps> = ({
 
 	const title =
 		status === agentVersionStatus.Outdated
-			? "Agent Outdated"
-			: "Agent Deprecated";
+			? "Workspace Daemon Outdated"
+			: "Workspace Daemon Deprecated";
 	const opener =
 		status === agentVersionStatus.Outdated
-			? "This agent is an older version than the Coder server."
-			: "This agent is using a deprecated version of the API.";
+			? "This workspace daemon is an older version than the Coder server."
+			: "This workspace daemon is using a deprecated version of the API.";
 	const text = `${opener} This can happen after you update Coder with running workspaces. To fix this, you can stop and start the workspace.`;
 
 	return (

site/src/modules/resources/AgentStatus.tsx

@@ -69,7 +69,7 @@ interface DevcontainerStatusProps {
 const StartTimeoutLifecycle: FC<AgentStatusProps> = ({ agent }) => {
 	return (
 		<HelpTooltip>
-			<HelpTooltipTrigger asChild role="status" aria-label="Agent timeout">
+			<HelpTooltipTrigger asChild role="status" aria-label="Workspace daemon timeout">
 				<TriangleAlertIcon css={styles.timeoutWarning} />
 			</HelpTooltipTrigger>
 

site/src/modules/resources/SSHButton/SSHButton.tsx

@@ -55,7 +55,7 @@ export const AgentSSHButton: FC<AgentSSHButtonProps> = ({
 							codeExample="coder config-ssh"
 						/>
 						<SSHStep
-							helpText="Connect to the agent:"
+							helpText="Connect to the workspace daemon:"
 							codeExample={`ssh ${agentName}.${workspaceName}.${workspaceOwnerUsername}.${sshSuffix}`}
 						/>
 					</Stack>

site/src/modules/resources/useAgentLogs.ts

@@ -38,7 +38,7 @@ export function useAgentLogs(
 		const socket = watchWorkspaceAgentLogs(agentId, { after: 0 });
 		socket.addEventListener("message", (e) => {
 			if (e.parseError) {
-				console.warn("Error parsing agent log: ", e.parseError);
+				console.warn("Error parsing workspace daemon log: ", e.parseError);
 				return;
 			}
 
@@ -58,8 +58,8 @@ export function useAgentLogs(
 		});
 
 		socket.addEventListener("error", (error) => {
-			console.error("Error in agent log socket: ", error);
-			toast.error(`Unable to watch "${agentId}" agent logs.`, {
+			console.error("Error in workspace daemon log socket: ", error);
+			toast.error(`Unable to watch "${agentId}" workspace daemon logs.`, {
 				description: "Please try refreshing the browser.",
 			});
 			socket.close();

site/src/modules/workspaces/WorkspaceTiming/StagesChart.tsx

@@ -292,7 +292,7 @@ export const agentStages = (section: string, agentId: string): Stage[] => {
 			agentId,
 			tooltip: {
 				heading: "Run startup scripts",
-				description: "Execute each agent startup script.",
+				description: "Execute each workspace daemon startup script.",
 			},
 		},
 	];

site/src/pages/ConnectionLogPage/ConnectionLogHelpTooltip.tsx

@@ -12,7 +12,7 @@ import { docs } from "utils/docs";
 
 const Language = {
 	title: "Why are some events missing?",
-	body: "The connection log is a best-effort log of workspace access. Some events are reported by workspace agents, and receipt of these events by the server is not guaranteed.",
+	body: "The connection log is a best-effort log of workspace access. Some events are reported by workspace daemons, and receipt of these events by the server is not guaranteed.",
 	docs: "Connection log documentation",
 };
 

site/src/pages/TerminalPage/TerminalPage.tsx

@@ -38,7 +38,7 @@ import type { ConnectionStatus } from "./types";
 
 export const Language = {
 	workspaceErrorMessagePrefix: "Unable to fetch workspace: ",
-	workspaceAgentErrorMessagePrefix: "Unable to fetch workspace agent: ",
+	workspaceAgentErrorMessagePrefix: "Unable to fetch workspace daemon: ",
 	websocketErrorMessagePrefix: "WebSocket failed: ",
 };
 

site/src/pages/WorkspacePage/Workspace.tsx

@@ -274,21 +274,21 @@ const UnhealthyWorkspaceAlert: FC<UnhealthyWorkspaceAlertProps> = ({
 		});
 	});
 
-	var title = "Workspace agents are not connected";
+	var title = "Workspace daemons are not connected";
 	var message =
-		"Your workspace cannot be used until an agent connects. Continue to wait and check the log output of your workspace for any errors.";
+		"Your workspace cannot be used until a workspace daemon connects. Continue to wait and check the log output of your workspace for any errors.";
 
 	// Disconnected is a more serious failure than timeout, so we can
 	// prioritize handling it first.
 	if (failureSet.has("disconnected")) {
-		title = "Workspace agents have disconnected";
+		title = "Workspace daemons have disconnected";
 		message =
-			"Continue to wait and check the log output of your workspace for any errors. If the agent does not reconnect, restarting the workspace can be used to try again.";
+			"Continue to wait and check the log output of your workspace for any errors. If the workspace daemon does not reconnect, restarting the workspace can be used to try again.";
 	} else if (failureSet.has("timeout")) {
 		// Handle timeout case
-		title = "Your workspace is starting, but the agent has not yet connected.";
+		title = "Your workspace is starting, but the workspace daemon has not yet connected.";
 		message =
-			"The agent is taking longer than expected to connect. Continue to wait and check the log output of your workspace for any errors. If the agent does not connect, restarting the workspace can be used to try again.";
+			"The workspace daemon is taking longer than expected to connect. Continue to wait and check the log output of your workspace for any errors. If the workspace daemon does not connect, restarting the workspace can be used to try again.";
 	}
 
 	return (
@@ -298,8 +298,8 @@ const UnhealthyWorkspaceAlert: FC<UnhealthyWorkspaceAlertProps> = ({
 				<p>
 					Your workspace is running but{" "}
 					{failingAgentCount > 1
-						? `${failingAgentCount} agents have not connected yet.`
-						: "the agent has not connected yet."}
+						? `${failingAgentCount} workspace daemons have not connected yet.`
+						: "the workspace daemon has not connected yet."}
 					.{" "}
 				</p>
 				<p>{message}</p>

site/src/pages/WorkspacePage/WorkspaceNotifications/WorkspaceNotifications.tsx

@@ -100,8 +100,8 @@ export const WorkspaceNotifications: FC<WorkspaceNotificationsProps> = ({
 				<>
 					Your workspace is running but{" "}
 					{workspace.health.failing_agents.length > 1
-						? `${workspace.health.failing_agents.length} agents are unhealthy`
-						: "1 agent is unhealthy"}
+						? `${workspace.health.failing_agents.length} workspace daemons are unhealthy`
+						: "1 workspace daemon is unhealthy"}
 					.
 				</>
 			),