nested shells make it harder to debug issues; document workarounds for better local dev

[jay-aye-see-kay]

What problem are you trying to solve?

When debugging devbox (and trying to submit a fix) many commands spawn a nested devbox subprocess with the --run-in-current-shell flag. The current process doesn't really do any work, just spawns the subprocess. This means adding debug logs and running devbox services up won't emit any - all the interesting stuff will happen in the subprocess, which is the installed version of devbox.

I have a couple workarounds but I feel this should be documented in the repo

What solution would you like?

The most robust fix I've found is instead of doing devbox run build && ./dist/devbox <whatever> (what I would expect to work)

1. build and move it

   devbox run build
   mkdir -p ~/.cache/devbox/bin/0.0.0-dev_darwin_arm64/
   mv dist/devbox ~/.cache/devbox/bin/0.0.0-dev_darwin_arm64/

2. then in any shell, any directory

   export DEVBOX_USE_VERSION=0.0.0-dev
   devbox <whatever>

Alternatives you've considered

An alternative fix is to pass the --run-in-current-shell flag, but this behavior will slightly differ from a real devbox build, meaning some issues can't be reproduced (in my current case).

./dist/devbox <whatever> --run-in-current-shell

[mikeland73]

This was fixed at the root in #2936: devbox services … now re-invokes the currently running binary (os.Executable()) rather than whatever devbox is first on PATH. As a result, devbox run build && ./dist/devbox <whatever> now behaves as you'd expect — the nested subprocess is your local build, so DEVBOX_DEBUG=1 logs and breakpoints fire end to end without the DEVBOX_USE_VERSION cache-copy step.

Thanks for the detailed write-up of the workarounds — it's what led to the actual fix.