Cloud container doesn't have node after setup finish

Also reported on universal image repo:
https://github.com/openai/codex-universal/issues/106

In interactive terminal with empty setup and maintenance scripts:

Starting test
Configuring container
Downloading repo
Running setup scripts
Configuring language runtimes...
Running setup scripts...
Finalizing container setup
Test complete
/workspace/*$ 
which go
/root/.local/share/mise/installs/go/1.25.1/bin/go
/workspace/*$ 
which node

/workspace/*$ 
which npm

/workspace/*$ 
which ruby
/root/.local/share/mise/installs/ruby/3.2.3/bin/ruby
/workspace/*$ 

Thanks to @Klathmon for the suggestion for a temp fix: https://github.com/openai/codex-universal/issues/106#issuecomment-3618244637

run nvm use <your_version> to inform the agent in your existing tasks.

for example I'm adding:
nvm use v20

I'm still not able to access NVM in the setup script.

Can confirm, a universal container suddenly cannot find "node" or "npm". When attaching the terminal in the "Edit environment" Web UI, you can see the npm command executed as a part of the starting script, but then npm is not available in the terminal. The agent task logs also show that it cannot run node and gets stuck trying to install it.
A bit of my terminal logs:

$ 
which npm

$ 
echo "$PATH"
/root/.pyenv/shims:/root/.pyenv/bin:/root/.local/share/mise/installs/bun/1.2.14/bin:/root/.local/share/mise/installs/erlang/27.1.2/bin:/root/.local/share/mise/installs/go/1.25.1/bin:/root/.local/share/mise/installs/golangci-lint/2.1.6/golangci-lint-2.1.6-linux-amd64:/root/.local/share/mise/installs/gradle/8.14.3/gradle-8.14.3/bin:/root/.local/share/mise/installs/java/21.0.2/bin:/root/.local/share/mise/installs/maven/3.9.10/apache-maven-3.9.10/bin:/root/.local/share/mise/installs/php/8.4.14/bin:/root/.local/share/mise/installs/php/8.4.14/sbin:/root/.local/share/mise/installs/php/8.4.14/.composer/vendor/bin:/root/.local/share/mise/installs/ruby/3.2.3/bin:/root/.local/share/mise/installs/swift/6.2/bin:/root/.local/share/mise/installs/elixir/1.18.3-otp-27/bin:/root/.local/share/mise/installs/elixir/1.18.3-otp-27/.mix/escripts:/root/.cargo/bin:/root/.pyenv/bin:/usr/local/go/bin:/root/go/bin:/root/.local/bin:/root/.pyenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ 
which node
$ 
which mise || mise --version
/usr/bin/mise

Well this is a rather embarrassing length of time to be entirely missing an entire language. No cloud development with Node. :(

Other than the workaround of having to install the package on startup is there ever expected to be a fix?

For a temporary fix -> Add this to the setup script along with your npm, pnpm, etc install commands. This should push the right nvm shims across to the agent sandbox and keep things appropriately cached across your env.

# TEMP: Hotfix till OpenAI gets their stuff together and figures out they nuked an entire language shim.

# Backup the existing bashrc
cp "$HOME/.bashrc" "$HOME/.bashrc.bak"

# Write the NVM block at the top of a fresh .bashrc
cat <<'EOF' > "$HOME/.bashrc"

# NVM setup
export NVM_DIR="$HOME/.nvm"

if [ -s "$NVM_DIR/nvm.sh" ]; then
  . "$NVM_DIR/nvm.sh" --no-use >/dev/null 2>&1
fi

if command -v nvm >/dev/null 2>&1; then
  nvm use --silent v20 >/dev/null 2>&1 || nvm install v20
fi

EOF

# Append the original contents (which includes the [ -z "$PS1" ] && return line)
cat "$HOME/.bashrc.bak" >> "$HOME/.bashrc"


source ~/.bashrc

pnpm install --frozen-lockfile

Another (albeit a bit silly) workaround is to add an instruction to your prompt, so the model could do it.
Something like that works for me: "your environment has some issues with node environment, make sure to run nvm use --lts before running node or npm commands", and it does this itself.

Another (albeit a bit silly) workaround is to add an instruction to your prompt, so the model could do it. Something like that works for me: "your environment has some issues with node environment, make sure to run nvm use --lts before running node or npm commands", and it does this itself.

@VitalyBrusentsev LMK if you are able to verify that this method preserves the npm cache across all task env's, as it is much simpler. I avoided doing this because I wanted to make sure I didn't have to redo fresh npm installations for every single cloud agent task.

@VitalyBrusentsev LMK if you are able to verify that this method preserves the npm cache across all task env's, as it is much simpler. I avoided doing this because I wanted to make sure I didn't have to redo fresh npm installations for every single cloud agent task.

No, it doesn't, so you would need to add it to every task. It's just a workaround for folks who don't want to mess with their standard container setup (while waiting for OpenAI to fix the issue).

🙏 Thank you for reporting the bug! We believe we have identified and triaged the bug; having to do with an optimization we introduced to speed up container set-up. Can y'all retry tasks and verify whether y'all are seeing the same behavior?

We got confirmation here, so I'm going to mark the issue as closed.