Proposed change to Goose desktop’s shell environment

[jamadeo]

Current state

Goose runs a login shell (actually three) at app startup and parses the output of env, and sets these in the GUI process. This not only contributes significantly to startup time, but is generally not expected behavior for desktop applications.

Proposal

Remove the login shell step. Setting environment variables should be handled differently depending on the use case:

Provider configuration (e.g. ANTHROPIC_API_KEY=...)

This should go in the provider config itself. If there’s an option we need to make available that isn’t there, we should fix it.

Extension configuration (e.g. GOOGLE_DRIVE_OAUTH_FILE=...)

Should go in the extension section of Goose’s config.yaml

Developer shell environment

Goose uses non-interactive bash (for linux/macos) for the shell tool. This means it should not source from .bash_profile (login shells) or .bashrc (interactive shells). Bash will read from a file pointed to by BASH_ENV. We should set this to ~/.config/goose/.bash_env. This means users can set whatever they want here, including sourcing other shell configs or .env files.

[michaelneale]

would you say similar to zsh which is now standard/default on macos @jamadeo I think?

I still can't square away the difference in behavior when someone running cli vs this... it will be quite stark (unless cli changes to match, when it run shell commands). For running the desktop itself, I think it is ok for it to do all this for the gui, but then when it spawns shells that is when it would get most surprising and hardest to resolve (ie specific to the developer mcp shell command etc).

[michaelneale]

I wonder what ideal is: cli would work as it does now - and when running shell commands from desktop it uses the users $SHELL and expected environment to run commands? (this makes it close to consistent with cli experience and principle of least surprise).

or is that really weird behavior and it should be more explicit? There aren't many other peers to compare with but curious what other things do here @jamadeo as I worry this would change things a lot

[michaelneale]

Goose uses non-interactive bash (for linux/macos) for the shell tool. This means it should not source from .bash_profile (login shells) or .bashrc (interactive shells)

yes makes sense - however when you run from cli today, the environment variables that have been obtained that way via the initial interactive shell the user opened (if an interactive shell) are carried over to any shell commands that goose then runs (which one would expect? ie you export a variable, run some goose... you would expect those to be there?)

[michaelneale]

(FYI in current version still does that, so CLI wise that makes sens)

[michaelneale]

#4702 a small suggestion to the change - use SHELL variable to decide what shell to use - falling back to bash, but otherwise, yes I think this all makes sense.

[michaelneale]

as @jamadeo points out - switching to zsh as $SHELL is also a change in behavior (and may be unfamiliar to LLMs)