same here any work around?

Apparently, since the exported functions are available inside the devbox environment, the workaround is just to ignore the error.

I'ld still love it for the error not to appear, though, as I wasted quite a bit of time trying to figure out what was wrong with my env.

@albx79 , same thing, I spent about a few hours trying to figure out what went wrong

$ devbox shell
✓ Computed the Devbox environment.
Starting a devbox shell...
/tmp/devbox504213459/.zshrc:export:12: not valid in this context: BASH_FUNC_ml%

For some reason devbox take working function from my env

ml()
{
  eval "$($LMOD_DIR/ml_cmd "$@")"
}

and create this

export BASH_FUNC_ml%%="() {  eval \"\$(\$LMOD_DIR/ml_cmd \"\$@\")\"\
}";

Debug info

$ cat  /tmp/devbox504213459/.zshrc | grep BASH_FUNC_ml%% -B 1 -A 1
export BASH_ENV="/usr/share/lmod/lmod/init/bash";
export BASH_FUNC_ml%%="() {  eval \"\$(\$LMOD_DIR/ml_cmd \"\$@\")\"\
}";

$ zsh --version
zsh 5.9 (x86_64-redhat-linux-gnu)

$ cat /etc/os-release
NAME="Fedora Linux"
VERSION="38 (Workstation Edition)"

$ devbox version
0.10.1

Look like it broke init_hook, it not running anymore

plugins (corepack in my case) fails to execute they hooks too

As I understand this code has this form intentionally, but I still can't figure out how to fix the error
https://antonyt.com/blog/2020-03-27/exploiting-cgi-scripts-with-shellshock

When i run devbox shell, I get this,

bash: export: `BASH_FUNC_which%%=() {  ( alias; eval ${which_declare} ) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot $@}': not a valid identifier

It doesn't seem to impact anything -- as other folks above have said, or is it really harmless? -- but it makes it hard for me to convince my team we should use this together.

Is there a flag or variable I can set in the dotenv.json file to bypass parsing or evaluating .bashrc or .bash_profile functions? Or is that misguided... that's part of devbox's charm I suppose when it all works smoothly?

It doesn't seem to impact anything -- as other folks above have said, or is it really harmless?

I already mentioned that it breaks running init scripts. In other words, everything that's written in 

"shell": {  
    "init_hook": [  
        "echo 'This will never executed'"  
     ]  
}  

Not working because of crash

For a Red Hat system, this causes problems because of which2.sh, found in /etc/profile.d. A workaround is to put unset which above the call to eval "$(devbox global shellenv)".