I've been thinking what the default behavior here should be. If no customization is set we could potentially inherit parent apps or defaults. It won't be the best experience if there are no apps by default.

(Currently in my other feature branch I default to using parent agent apps as a placeholder.)

Yeah, I thought about this as well. I think inheriting parentdisplay apps (notcoder_apps) is definitely an option, although we could also have a default of "vscode", "web_terminal", and "ssh_helper"? That should cover a basic use-case.

As for inheriting "apps", I think that wouldn't work as many (or all?) work based on agent name, so copying it 1:1 would mean the app is visible but would just connect you to the parent agent instead of the sub agent.

Yeah, sorry for being unclear. I was only referring to display apps here, not other apps 👍🏻

This is unfortunate. Any particular thing it choked on?

Btw, I notice there's no "merged" configuration. I suppose we won't get customizations added by features etc here?

They aren't 1:1 on schema.

{  "configuration": {    "name": "Development environments on your infrastructure",    "image": "codercom/oss-dogfood:latest",    "features": {      "ghcr.io/devcontainers/features/docker-in-docker:2": {        "moby": "false"      }    },    "runArgs": [      "--cap-add=SYS_PTRACE"    ],    "customizations": {      "vscode": {        "extensions": [          "biomejs.biome"        ]      }    },    "configFilePath": {      "$mid": 1,      "fsPath": "/home/coder/coder/.devcontainer/devcontainer.json",      "path": "/home/coder/coder/.devcontainer/devcontainer.json",      "scheme": "vscode-fileHost"    }  },  "workspace": {    "workspaceFolder": "/workspaces/coder",    "workspaceMount": "type=bind,source=/home/coder/coder,target=/workspaces/coder"  }}

If I runcat agent/agentcontainers/dcspec/devContainer.base.schema.json | rg 'configFilePath', it shows no results. Maybe it is just that field but it is definitely a little unfortunate.

I don't see thatconfigFilePath is needed for anything since we already know it, or am I missing something?

Did you consider container ID and include merged?

I suppose there is no harm in adding container ID, or including merged, but I don't think they're strictly needed.

From our slack discussion it appears weneed to use on-disk configuration to have all the variables substituted correctly, and this on-disk configuration takes priority over the container's configuration. For this reason I decided against using the container ID.

I suppose we could make use ofmerged? For now I've only implemented the absolute minimum we need, but maybe there is a use-case for merged config that I've missed?

If we're only considering display apps, then the only use-case I can think of is having a Coder base-feature for all your devcontainers that sets some default customizations.

Considering merged gives us both the on-disk config and potential additions from container/features, it seems to me like the best way to handle all potential configuration needs, rather than occasionally using merged and other times not.