Nov 26, 2025 · Nov 26, 2025 · Nov 26, 2025 · Nov 26, 2025 · Nov 26, 2025 · Nov 26, 2025
diff --git a/.claude/docs/ARCHITECTURE.md b/.claude/docs/ARCHITECTURE.md
 # Coder Architecture

 This document provides an overview of Coder's architecture and core systems.

 ## What is Coder?

 Coder is a platform for creating, managing, and using remote development environments (also known as Cloud Development Environments or CDEs). It leverages Terraform to define and provision these environments, which are referred to as "workspaces" within the project. The system is designed to be extensible, secure, and provide developers with a seamless remote development experience.

 ## Core Architecture

 The heart of Coder is a control plane that orchestrates the creation and management of workspaces. This control plane interacts with separate Provisioner processes over gRPC to handle workspace builds. The Provisioners consume workspace definitions and use Terraform to create the actual infrastructure.

 The CLI package serves dual purposes - it can be used to launch the control plane itself and also provides client functionality for users to interact with an existing control plane instance. All user-facing frontend code is developed in TypeScript using React and lives in the `site/` directory.

 The database layer uses PostgreSQL with SQLC for generating type-safe database code. Database migrations are carefully managed to ensure both forward and backward compatibility through paired `.up.sql` and `.down.sql` files.

 ## API Design

 Coder's API architecture combines REST and gRPC approaches. The REST API is defined in `coderd/coderd.go` and uses Chi for HTTP routing. This provides the primary interface for the frontend and external integrations.

 Internal communication with Provisioners occurs over gRPC, with service definitions maintained in `.proto` files. This separation allows for efficient binary communication with the components responsible for infrastructure management while providing a standard REST interface for human-facing applications.

 ## Network Architecture

 Coder implements a secure networking layer based on Tailscale's Wireguard implementation. The `tailnet` package provides connectivity between workspace agents and clients through DERP (Designated Encrypted Relay for Packets) servers when direct connections aren't possible. This creates a secure overlay network allowing access to workspaces regardless of network topology, firewalls, or NAT configurations.

 ### Tailnet and DERP System

 The networking system has three key components:

 1. **Tailnet**: An overlay network implemented in the `tailnet` package that provides secure, end-to-end encrypted connections between clients, the Coder server, and workspace agents.

 2. **DERP Servers**: These relay traffic when direct connections aren't possible. Coder provides several options:
   - A built-in DERP server that runs on the Coder control plane
   - Integration with Tailscale's global DERP infrastructure
   - Support for custom DERP servers for lower latency or offline deployments

 3. **Direct Connections**: When possible, the system establishes peer-to-peer connections between clients and workspaces using STUN for NAT traversal. This requires both endpoints to send UDP traffic on ephemeral ports.

 ### Workspace Proxies

 Workspace proxies (in the Enterprise edition) provide regional relay points for browser-based connections, reducing latency for geo-distributed teams. Key characteristics:

 - Deployed as independent servers that authenticate with the Coder control plane
 - Relay connections for SSH, workspace apps, port forwarding, and web terminals
 - Do not make direct database connections
 - Managed through the `coder wsproxy` commands
 - Implemented primarily in the `enterprise/wsproxy/` package

 ## Agent System

 The workspace agent runs within each provisioned workspace and provides core functionality including:

 - SSH access to workspaces via the `agentssh` package
 - Port forwarding
 - Terminal connectivity via the `pty` package for pseudo-terminal support
 - Application serving
 - Healthcheck monitoring
 - Resource usage reporting

 Agents communicate with the control plane using the tailnet system and authenticate using secure tokens.

 ## Workspace Applications

 Workspace applications (or "apps") provide browser-based access to services running within workspaces. The system supports:

 - HTTP(S) and WebSocket connections
 - Path-based or subdomain-based access URLs
 - Health checks to monitor application availability
 - Different sharing levels (owner-only, authenticated users, or public)
 - Custom icons and display settings

 The implementation is primarily in the `coderd/workspaceapps/` directory with components for URL generation, proxying connections, and managing application state.

 ## Implementation Details

 The project structure separates frontend and backend concerns. React components and pages are organized in the `site/src/` directory, with Jest used for testing. The backend is primarily written in Go, with a strong emphasis on error handling patterns and test coverage.

 Database interactions are carefully managed through migrations in `coderd/database/migrations/` and queries in `coderd/database/queries/`. All new queries require proper database authorization (dbauthz) implementation to ensure that only users with appropriate permissions can access specific resources.

 ## Authorization System

 The database authorization (dbauthz) system enforces fine-grained access control across all database operations. It uses role-based access control (RBAC) to validate user permissions before executing database operations. The `dbauthz` package wraps the database store and performs authorization checks before returning data. All database operations must pass through this layer to ensure security.

 ## Testing Framework

 The codebase has a comprehensive testing approach with several key components:

 1. **Parallel Testing**: All tests must use `t.Parallel()` to run concurrently, which improves test suite performance and helps identify race conditions.

 2. **coderdtest Package**: This package in `coderd/coderdtest/` provides utilities for creating test instances of the Coder server, setting up test users and workspaces, and mocking external components.

 3. **Integration Tests**: Tests often span multiple components to verify system behavior, such as template creation, workspace provisioning, and agent connectivity.

 4. **Enterprise Testing**: Enterprise features have dedicated test utilities in the `coderdenttest` package.

 ## Open Source and Enterprise Components

 The repository contains both open source and enterprise components:

 - Enterprise code lives primarily in the `enterprise/` directory
 - Enterprise features focus on governance, scalability (high availability), and advanced deployment options like workspace proxies
 - The boundary between open source and enterprise is managed through a licensing system
 - The same core codebase supports both editions, with enterprise features conditionally enabled

 ## Development Philosophy

 Coder emphasizes clear error handling, with specific patterns required:

 - Concise error messages that avoid phrases like "failed to"
 - Wrapping errors with `%w` to maintain error chains
 - Using sentinel errors with the "err" prefix (e.g., `errNotFound`)

 All tests should run in parallel using `t.Parallel()` to ensure efficient testing and expose potential race conditions. The codebase is rigorously linted with golangci-lint to maintain consistent code quality.

 Git contributions follow a standard format with commit messages structured as `type: <message>`, where type is one of `feat`, `fix`, or `chore`.

 ## Development Workflow

 Development can be initiated using `scripts/develop.sh` to start the application after making changes. Database schema updates should be performed through the migration system using `create_migration.sh <name>` to generate migration files, with each `.up.sql` migration paired with a corresponding `.down.sql` that properly reverts all changes.

 If the development database gets into a bad state, it can be completely reset by removing the PostgreSQL data directory with `rm -rf .coderv2/postgres`. This will destroy all data in the development database, requiring you to recreate any test users, templates, or workspaces after restarting the application.

 Code generation for the database layer uses `coderd/database/generate.sh`, and developers should refer to `sqlc.yaml` for the appropriate style and patterns to follow when creating new queries or tables.

 The focus should always be on maintaining security through proper database authorization, clean error handling, and comprehensive test coverage to ensure the platform remains robust and reliable.
diff --git a/.cursorrules b/.cursorrules
diff --git a/.cursorrules b/.cursorrules
 AGENTS.md
diff --git a/CLAUDE.md b/CLAUDE.md
 - Follow [Uber Go Style Guide](https://github.com/uber-go/guide/blob/master/style.md)
 - Commit format: `type(scope): message`

 ### Writing Comments

 Code comments should be clear, well-formatted, and add meaningful context.

 **Proper sentence structure**: Comments are sentences and should end with
 periods or other appropriate punctuation. This improves readability and
 maintains professional code standards.

 **Explain why, not what**: Good comments explain the reasoning behind code
 rather than describing what the code does. The code itself should be
 self-documenting through clear naming and structure. Focus your comments on
 non-obvious decisions, edge cases, or business logic that isn't immediately
 apparent from reading the implementation.

 **Line length and wrapping**: Keep comment lines to 80 characters wide
 (including the comment prefix like `//` or `#`). When a comment spans multiple
 lines, wrap it naturally at word boundaries rather than writing one sentence
 per line. This creates more readable, paragraph-like blocks of documentation.

 ```go
 // Good: Explains the rationale with proper sentence structure.
 // We need a custom timeout here because workspace builds can take several
 // minutes on slow networks, and the default 30s timeout causes false
 // failures during initial template imports.
 ctx, cancel := context.WithTimeout(ctx, 5*time.Minute)

 // Bad: Describes what the code does without punctuation or wrapping
 // Set a custom timeout
 // Workspace builds can take a long time
 // Default timeout is too short
 ctx, cancel := context.WithTimeout(ctx, 5*time.Minute)
 ```

 ## Detailed Development Guides

 @.claude/docs/ARCHITECTURE.md
 @.claude/docs/OAUTH2.md
 @.claude/docs/TESTING.md
 @.claude/docs/TROUBLESHOOTING.md
diff --git a/cli/clitest/clitest.go b/cli/clitest/clitest.go
 t testing.TB, cmd *serpent.Command, args ...string,
 ) (*serpent.Invocation, config.Root) {
 configDir := config.Root(t.TempDir())
 // Keyring usage is disabled herebecause many existing tests expect the session token
 // to be stored on disk and is not properly instrumented for parallel testing against
 // the actual operating system keyring.
 invArgs := append([]string{"--global-config", string(configDir), "--use-keyring=false"}, args...)
 // Keyring usage is disabled herewhen --global-config is set because many existing
 //tests expect the session tokento be stored on disk and is not properly instrumented
 //for parallel testing againstthe actual operating system keyring.
 invArgs := append([]string{"--global-config", string(configDir)}, args...)
 return setupInvocation(t, cmd, invArgs...), configDir
 }
Original file line number	Diff line number	Diff line change
		@@ -0,0 +1,126 @@
		# Coder Architecture

		This document provides an overview of Coder's architecture and core systems.

		## What is Coder?

		Coder is a platform for creating, managing, and using remote development environments (also known as Cloud Development Environments or CDEs). It leverages Terraform to define and provision these environments, which are referred to as "workspaces" within the project. The system is designed to be extensible, secure, and provide developers with a seamless remote development experience.

		## Core Architecture

		The heart of Coder is a control plane that orchestrates the creation and management of workspaces. This control plane interacts with separate Provisioner processes over gRPC to handle workspace builds. The Provisioners consume workspace definitions and use Terraform to create the actual infrastructure.

		The CLI package serves dual purposes - it can be used to launch the control plane itself and also provides client functionality for users to interact with an existing control plane instance. All user-facing frontend code is developed in TypeScript using React and lives in the `site/` directory.

		The database layer uses PostgreSQL with SQLC for generating type-safe database code. Database migrations are carefully managed to ensure both forward and backward compatibility through paired `.up.sql` and `.down.sql` files.

		## API Design

		Coder's API architecture combines REST and gRPC approaches. The REST API is defined in `coderd/coderd.go` and uses Chi for HTTP routing. This provides the primary interface for the frontend and external integrations.

		Internal communication with Provisioners occurs over gRPC, with service definitions maintained in `.proto` files. This separation allows for efficient binary communication with the components responsible for infrastructure management while providing a standard REST interface for human-facing applications.

		## Network Architecture

		Coder implements a secure networking layer based on Tailscale's Wireguard implementation. The `tailnet` package provides connectivity between workspace agents and clients through DERP (Designated Encrypted Relay for Packets) servers when direct connections aren't possible. This creates a secure overlay network allowing access to workspaces regardless of network topology, firewalls, or NAT configurations.

		### Tailnet and DERP System

		The networking system has three key components:

		1. Tailnet: An overlay network implemented in the `tailnet` package that provides secure, end-to-end encrypted connections between clients, the Coder server, and workspace agents.

		2. DERP Servers: These relay traffic when direct connections aren't possible. Coder provides several options:
		- A built-in DERP server that runs on the Coder control plane
		- Integration with Tailscale's global DERP infrastructure
		- Support for custom DERP servers for lower latency or offline deployments

		3. Direct Connections: When possible, the system establishes peer-to-peer connections between clients and workspaces using STUN for NAT traversal. This requires both endpoints to send UDP traffic on ephemeral ports.

		### Workspace Proxies

		Workspace proxies (in the Enterprise edition) provide regional relay points for browser-based connections, reducing latency for geo-distributed teams. Key characteristics:

		- Deployed as independent servers that authenticate with the Coder control plane
		- Relay connections for SSH, workspace apps, port forwarding, and web terminals
		- Do not make direct database connections
		- Managed through the `coder wsproxy` commands
		- Implemented primarily in the `enterprise/wsproxy/` package

		## Agent System

		The workspace agent runs within each provisioned workspace and provides core functionality including:

		- SSH access to workspaces via the `agentssh` package
		- Port forwarding
		- Terminal connectivity via the `pty` package for pseudo-terminal support
		- Application serving
		- Healthcheck monitoring
		- Resource usage reporting

		Agents communicate with the control plane using the tailnet system and authenticate using secure tokens.

		## Workspace Applications

		Workspace applications (or "apps") provide browser-based access to services running within workspaces. The system supports:

		- HTTP(S) and WebSocket connections
		- Path-based or subdomain-based access URLs
		- Health checks to monitor application availability
		- Different sharing levels (owner-only, authenticated users, or public)
		- Custom icons and display settings

		The implementation is primarily in the `coderd/workspaceapps/` directory with components for URL generation, proxying connections, and managing application state.

		## Implementation Details

		The project structure separates frontend and backend concerns. React components and pages are organized in the `site/src/` directory, with Jest used for testing. The backend is primarily written in Go, with a strong emphasis on error handling patterns and test coverage.

		Database interactions are carefully managed through migrations in `coderd/database/migrations/` and queries in `coderd/database/queries/`. All new queries require proper database authorization (dbauthz) implementation to ensure that only users with appropriate permissions can access specific resources.

		## Authorization System

		The database authorization (dbauthz) system enforces fine-grained access control across all database operations. It uses role-based access control (RBAC) to validate user permissions before executing database operations. The `dbauthz` package wraps the database store and performs authorization checks before returning data. All database operations must pass through this layer to ensure security.

		## Testing Framework

		The codebase has a comprehensive testing approach with several key components:

		1. Parallel Testing: All tests must use `t.Parallel()` to run concurrently, which improves test suite performance and helps identify race conditions.

		2. coderdtest Package: This package in `coderd/coderdtest/` provides utilities for creating test instances of the Coder server, setting up test users and workspaces, and mocking external components.

		3. Integration Tests: Tests often span multiple components to verify system behavior, such as template creation, workspace provisioning, and agent connectivity.

		4. Enterprise Testing: Enterprise features have dedicated test utilities in the `coderdenttest` package.

		## Open Source and Enterprise Components

		The repository contains both open source and enterprise components:

		- Enterprise code lives primarily in the `enterprise/` directory
		- Enterprise features focus on governance, scalability (high availability), and advanced deployment options like workspace proxies
		- The boundary between open source and enterprise is managed through a licensing system
		- The same core codebase supports both editions, with enterprise features conditionally enabled

		## Development Philosophy

		Coder emphasizes clear error handling, with specific patterns required:

		- Concise error messages that avoid phrases like "failed to"
		- Wrapping errors with `%w` to maintain error chains
		- Using sentinel errors with the "err" prefix (e.g., `errNotFound`)

		All tests should run in parallel using `t.Parallel()` to ensure efficient testing and expose potential race conditions. The codebase is rigorously linted with golangci-lint to maintain consistent code quality.

		Git contributions follow a standard format with commit messages structured as `type: <message>`, where type is one of `feat`, `fix`, or `chore`.

		## Development Workflow

		Development can be initiated using `scripts/develop.sh` to start the application after making changes. Database schema updates should be performed through the migration system using `create_migration.sh <name>` to generate migration files, with each `.up.sql` migration paired with a corresponding `.down.sql` that properly reverts all changes.

		If the development database gets into a bad state, it can be completely reset by removing the PostgreSQL data directory with `rm -rf .coderv2/postgres`. This will destroy all data in the development database, requiring you to recreate any test users, templates, or workspaces after restarting the application.

		Code generation for the database layer uses `coderd/database/generate.sh`, and developers should refer to `sqlc.yaml` for the appropriate style and patterns to follow when creating new queries or tables.

		The focus should always be on maintaining security through proper database authorization, clean error handling, and comprehensive test coverage to ensure the platform remains robust and reliable.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -140,8 +140,42 @@ seems like it should use `time.Sleep`, read through https://github.com/coder/qua
		- Follow [Uber Go Style Guide](https://github.com/uber-go/guide/blob/master/style.md)
		- Commit format: `type(scope): message`

		### Writing Comments

		Code comments should be clear, well-formatted, and add meaningful context.

		Proper sentence structure: Comments are sentences and should end with
		periods or other appropriate punctuation. This improves readability and
		maintains professional code standards.

		Explain why, not what: Good comments explain the reasoning behind code
		rather than describing what the code does. The code itself should be
		self-documenting through clear naming and structure. Focus your comments on
		non-obvious decisions, edge cases, or business logic that isn't immediately
		apparent from reading the implementation.

		Line length and wrapping: Keep comment lines to 80 characters wide
		(including the comment prefix like `//` or `#`). When a comment spans multiple
		lines, wrap it naturally at word boundaries rather than writing one sentence
		per line. This creates more readable, paragraph-like blocks of documentation.

		```go
		// Good: Explains the rationale with proper sentence structure.
		// We need a custom timeout here because workspace builds can take several
		// minutes on slow networks, and the default 30s timeout causes false
		// failures during initial template imports.
		ctx, cancel := context.WithTimeout(ctx, 5*time.Minute)

		// Bad: Describes what the code does without punctuation or wrapping
		// Set a custom timeout
		// Workspace builds can take a long time
		// Default timeout is too short
		ctx, cancel := context.WithTimeout(ctx, 5*time.Minute)
		```

		## Detailed Development Guides

		@.claude/docs/ARCHITECTURE.md
		@.claude/docs/OAUTH2.md
		@.claude/docs/TESTING.md
		@.claude/docs/TROUBLESHOOTING.md
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -61,10 +61,10 @@ func NewWithCommand(
		t testing.TB, cmd *serpent.Command, args ...string,
		) (*serpent.Invocation, config.Root) {
		configDir := config.Root(t.TempDir())
		// Keyring usage is disabled herebecause many existing tests expect the session token
		// to be stored on disk and is not properly instrumented for parallel testing against
		// the actual operating system keyring.
		invArgs := append([]string{"--global-config", string(configDir), "--use-keyring=false"}, args...)
		// Keyring usage is disabled herewhen --global-config is set because many existing
		//tests expect the session tokento be stored on disk and is not properly instrumented
		//for parallel testing againstthe actual operating system keyring.
		invArgs := append([]string{"--global-config", string(configDir)}, args...)
		return setupInvocation(t, cmd, invArgs...), configDir
		}

Expand Down