Summary
Project discovery only matches .devcontainer/devcontainer.json and .devcontainer.json, so configurations in sub-folders (.devcontainer/<folder>/devcontainer.json) are never discovered and never show up as dev container cards in the dashboard.
This contradicts both the dev container spec and Coder's own documentation. docs/user-guides/devcontainers/index.md lists three supported locations, including:
.devcontainer/<folder>/devcontainer.json (for multiple configurations)
The third option allows monorepos to define multiple dev container configurations in separate sub-folders.
Steps to reproduce
-
In a workspace with dev containers integration and project discovery enabled, create a repository with only a sub-folder configuration:
myrepo/.devcontainer/python/devcontainer.json
-
Restart the workspace (or trigger discovery).
-
No dev container card appears in the dashboard.
A repository with .devcontainer/devcontainer.json at the conventional location is discovered fine.
Root cause
discoverDevcontainersInProject in agent/agentcontainers/api.go only matches two path suffixes:
devcontainerConfigPaths := []string{
"/.devcontainer/devcontainer.json",
"/.devcontainer.json",
}
|
devcontainerConfigPaths := []string{ |
|
"/.devcontainer/devcontainer.json", |
|
"/.devcontainer.json", |
|
} |
Note that the rest of the integration already handles sub-folder configs: containers started manually with devcontainer up --config .devcontainer/<folder>/devcontainer.json are picked up via the devcontainer.config_file container label and get a working sub-agent. Only discovery is affected, which leaves monorepo users with "works from the CLI, invisible in the dashboard".
Suggested fix (minimal)
Extend the matching in discoverDevcontainersInProject to also accept /.devcontainer/<dir>/devcontainer.json (one level deep, per the spec). When multiple configurations resolve to the same workspace folder, prefer the conventional locations and log a warning for the rest, since knownDevcontainers is currently keyed by workspace folder and can only represent one config per project.
Properly representing multiple configurations per project (multiple cards per repo, distinct sub-agent names) requires reworking that keying and is probably better treated as a follow-up. Happy to send a PR for the minimal fix.
Summary
Project discovery only matches
.devcontainer/devcontainer.jsonand.devcontainer.json, so configurations in sub-folders (.devcontainer/<folder>/devcontainer.json) are never discovered and never show up as dev container cards in the dashboard.This contradicts both the dev container spec and Coder's own documentation. docs/user-guides/devcontainers/index.md lists three supported locations, including:
Steps to reproduce
In a workspace with dev containers integration and project discovery enabled, create a repository with only a sub-folder configuration:
Restart the workspace (or trigger discovery).
No dev container card appears in the dashboard.
A repository with
.devcontainer/devcontainer.jsonat the conventional location is discovered fine.Root cause
discoverDevcontainersInProjectinagent/agentcontainers/api.goonly matches two path suffixes:coder/agent/agentcontainers/api.go
Lines 501 to 504 in ba64724
Note that the rest of the integration already handles sub-folder configs: containers started manually with
devcontainer up --config .devcontainer/<folder>/devcontainer.jsonare picked up via thedevcontainer.config_filecontainer label and get a working sub-agent. Only discovery is affected, which leaves monorepo users with "works from the CLI, invisible in the dashboard".Suggested fix (minimal)
Extend the matching in
discoverDevcontainersInProjectto also accept/.devcontainer/<dir>/devcontainer.json(one level deep, per the spec). When multiple configurations resolve to the same workspace folder, prefer the conventional locations and log a warning for the rest, sinceknownDevcontainersis currently keyed by workspace folder and can only represent one config per project.Properly representing multiple configurations per project (multiple cards per repo, distinct sub-agent names) requires reworking that keying and is probably better treated as a follow-up. Happy to send a PR for the minimal fix.