`make devcontainer-up` fails if `devcontainer` is already installed using `homebrew`

[djanjic]

Pre-requisites

• [x] I have double-checked my configuration
• [x] I have tested with the :latest image tag (i.e. quay.io/argoproj/workflow-controller:latest) and can confirm the issue still exists on :latest. If not, I have explained why, in detail, in my description below.
• [x] I have searched existing issues and could not find a match for this bug
• [ ] I'd like to contribute the fix myself (see contributing guide)

What happened? What did you expect to happen?

make devcontainer-up fails if devcontainer is already installed. On my machine, devcontainer CLI is installed using homebrew and npm list -g @devcontainers/[email protected] command is not detecting it. After that, it tries to install it and fails.

~ make devcontainer-up
GIT_COMMIT=44f9ea7fed2266321f1e16bff5dcb06a7cd80523 GIT_BRANCH=main GIT_TAG=untagged GIT_TREE_STATE=dirty RELEASE_TAG=false DEV_BRANCH=false VERSION=latest
KUBECTX=docker-desktop K3D=false DOCKER_PUSH=false TARGET_PLATFORM=linux/arm64
RUN_MODE=local PROFILE=minimal AUTH_MODE=hybrid SECURE=false  STATIC_FILES=true ALWAYS_OFFLOAD_NODE_STATUS=false UPPERIO_DB_DEBUG=0 LOG_LEVEL=debug NAMESPACED=true
npm list -g @devcontainers/[email protected] > /dev/null || npm i -g @devcontainers/[email protected]
npm error code EEXIST
npm error path /opt/homebrew/bin/devcontainer
npm error EEXIST: file already exists
npm error File exists: /opt/homebrew/bin/devcontainer
npm error Remove the existing file and try again, or run npm
npm error with --force to overwrite files recklessly.
npm error A complete log of this run can be found in: /Users/darkojanjic/.npm/_logs/2025-05-27T09_12_13_370Z-debug-0.log
make: *** [/opt/homebrew/bin/devcontainer] Error 1

~ npm list -g @devcontainers/[email protected]
/opt/homebrew/lib
└── (empty)

~ which devcontainer
/opt/homebrew/bin/devcontainer

Version(s)

:latest, 567819ac357707a467c1e12798411cee1785877c

Paste a minimal workflow that reproduces the issue. We must be able to run the workflow; don't enter a workflow that uses private images.

Just run `make devcontainer-up` on machine where `devcontainer CLI` is installed using `homebrew`.

Logs from the workflow controller

N/A

Logs from in your workflow's wait container

N/A

[Joibel]

@MasonM - you're developing on a mac as well? What does your setup look like?

[MasonM]

@Joibel Sometimes, but I switched from Homebrew to Nix, and I don't run make devcontainer-up on that machine.

I suspect almost all the other TOOL_* commands are going to have the same problem (e.g. make docs-lint will fail if you installed markdownlint via homebrew). I noticed TOOL_CLANG_FORMAT has an extra which clang-format check, which should avoid this: https://github.com/argoproj/argo-workflows/blob/ea2cc791be47ead4d56b13b31febfd4a6d454156/Makefile#L391-L392

[cw-Guo]

tried to reproduce this issue but failed.

 npm list -g @devcontainers/[email protected]
/opt/homebrew/lib
└── (empty)

~ ❯ which devcontainer
/opt/homebrew/bin/devcontainer

~/p/o/argo-workflows main ❯ make devcontainer-up
GIT_COMMIT=629eb21715f484144effb1bd3223b29e1e4813e3 GIT_BRANCH=main GIT_TAG=untagged GIT_TREE_STATE=clean RELEASE_TAG=false DEV_BRANCH=false VERSION=latest
KUBECTX=kind-k8s-playground K3D=false DOCKER_PUSH=false TARGET_PLATFORM=linux/arm64
RUN_MODE=local PROFILE=minimal AUTH_MODE=hybrid SECURE=false  STATIC_FILES=true ALWAYS_OFFLOAD_NODE_STATUS=false UPPERIO_DB_DEBUG=0 LOG_LEVEL=debug NAMESPACED=true
devcontainer up --workspace-folder .
[1 ms] @devcontainers/cli 0.80.0. Node.js v24.5.0. darwin 24.5.0 arm64.
[780 ms] Start: Run: docker run --sig-proxy=false -a STDOUT -a STDERR --mount

[SinnoLn]

Hi @cw-Guo,

Just wanted to follow up on this. I was able to find a consistent way to reproduce the original EEXIST error, and I believe this explains why it was difficult to reproduce in your environment.

The key was to set the npm prefix to match the Homebrew path (npm config set prefix /opt/homebrew), which intentionally creates a direct file conflict. It seems your environment likely had a default npm prefix, which avoided this issue.

I've submitted PR #14758 which resolves this for all environments by using a more robust which check, as @MasonM originally suggested.

Hope this provides some clarity!