Don't load user's shell env on app startup

[jamadeo]

This speeds up startup quite a lot. I don't think we need to do it (and definitely not three times)

[michaelneale]

@jamadeo not sure how it worked on your machine yesterday, but trying it packaged today:

1. It couldn't see my ANTHROPIC_API_KEY which was in env var (I tried adding it to config.yaml - but it doesnt' read it from there). I then added it as a provider the standard way (keychain) and made a new session - that is first issue (minor?)

2. (more serious) couldn't run developer extension as there is no working dir:

rmcp_developer.rs:183:43:\nshould have a current working dir

Longer:

Error activating extension: Failed to add extension configuration, error: ProcessExit(ProcessExit { stderr: "  \u{1b}[2m2025-09-19T17:57:10.433264Z\u{1b}[0m \u{1b}[32m INFO\u{1b}[0m \u{1b}[1;32mgoosed::commands::mcp\u{1b}[0m\u{1b}[32m: \u{1b}[32mStarting MCP server\u{1b}[0m\n    \u{1b}[2;3mat\u{1b}[0m crates/goose-server/src/commands/mcp.rs:19\n\n  \u{1b}[2m2025-09-19T17:57:10.433686Z\u{1b}[0m \u{1b}[32m INFO\u{1b}[0m \u{1b}[1;32mgoose_mcp::developer::analyze::cache\u{1b}[0m\u{1b}[32m: \u{1b}[32mInitializing analysis cache with size 100\u{1b}[0m\n    \u{1b}[2;3mat\u{1b}[0m crates/goose-mcp/src/developer/analyze/cache.rs:25\n\n\nthread 'main' panicked at crates/goose-mcp/src/developer/rmcp_developer.rs:183:43:\nshould have a current working dir: Os { code: 1, kind: PermissionDenied, message: \"Operation not permitted\" }\nnote: run with `RUST_BACKTRACE=1` environment variable to display a backtrace\n", source: ConnectionClosed("initialize response") })

[michaelneale]

@jamadeo I think worth continuing this, but still couldn't work out how to make sure goosed and thus developer MCP has a pwd - removing that code means that while shell calls may work (I suspect what you model did first) the actual spawned mcps do not know their session dir somehow, not sure what process variable is missing yet... but certainly faster if we can make it work!

[michaelneale]

@jamadeo actually scratch that last bit - I think on main I still see that, so may be my environment if you don't see it?

Main thing is that it doesn't load any old variable from config.yaml (in the occasional case you want to set provider + api key as a variable I guess? not sure what edge cases other than that, but probably not much).

[jamadeo]

@michaelneale I can't reproduce any issue with the working directory (I'm asking the model to run pwd or echo $PWD in shell)

For the config, what do we really want to do there? I typically wouldn't expect a desktop app to execute by bash/zsh configs to read their environment. I'd expect to put everything in Goose's config.yaml or UI directly (for secret values e.g.)

If we definitely want a way to set environment variables in the Goose process, we could consider having an env section of config.yaml maybe? but that means we'll probably end up with config split between actual config variables and env variables, which doesn't seem great

[michaelneale]

@jamadeo yeah - I think its just my environment.

On variables - it is pretty common for other systems to have an env: section like you said, which can be inline or pick from the environment around it (although the latter in this case I don't think would work as when it starts from an .app - there is nothing there really, I think anyway...). we do already have VARIABLE_NAME in config.yaml used for other parts but then it is a big leap to make it pick up any pattern.

The example I saw fail was anthropic, which uses pub fn get_secret in base.rs:

/// Get a secret value.
    ///
    /// This will attempt to get the value from:
    /// 1. Environment variable with the exact key name
    /// 2. System keyring

I'm not sure this will work with environment as there is no environment when run as an .app (but again may be my env! maybe can double check that?) worth checking out. In that specific case, secret store is probably ok, but if it trips up this, could be a ton of other unseen things.

[michaelneale]

ok after clearing out Application Support/Goose dir, I can run this (and is fast) - however, even with shell commands it doesn't have access to the users shell variables (ie add some variable to .zshrc - then ask goose "tell me the value of $THING" ). I think that may be perhaps the bigger issue than config environment variables? (ie a developer using the developer SDK would have reason to think it would have a similar environment to their default/preferred shell?). It can source it if needed I guess...

interestingly in the developer toolkit:

            // Use bash on Unix/macOS (keep existing behavior)
            Self {
                executable: "bash".to_string(),
                args: vec!["-c".to_string()],
            }

even if I change that to zsh (hard coded - although it should honour $SHELL ideally), it doesn't automatically source .zshrc (!) when running shell commands, which seems really odd (this wouldn't be noticed when we forcibly source .zshrc so if this is a bug in developer mcp, then it is being hidden and now exposed).

In any case, this behaves differently to goose cli (given it starts from a shell of course). Obviously a non issue on linux (and windows) and for non zsh macos users as it was always this way - but a bit of a departure otherwise I think.. interesting..

[jamadeo]

I wonder what we want to support here. What are the main use cases for passing env from shell config files? I think for Goose itself, you mainly want to pass vars to either MCP extensions or providers, and both of those have other (better) mechanisms.

The developer shell is an interesting use case. I wonder if it's possible for the goose shell tool to start a single login shell using $SHELL, and spawn all other shells from that? Or at least just do this login shell env reading in the developer MCP instead of app startup. That is, if we do want to make this work.

[jamadeo]

@michaelneale I think BASH_ENV might be the key to all of this. If set, any bash process sources from this file. We can set it to a location in Goose's config dir, letting the user set up their Goose shell env however they want.

[jamadeo]

Opened #4695 to allow a specific discussion

[michaelneale]

@jamadeo on mac I think everyone uses zsh these days, would BASH_ENV work for that the same? I'm not sure about changing cli behavior here though.

[michaelneale]

hrm - is this an issue adding in the goose dep to mcp?

[michaelneale]

(feels circular but isn't...)

[michaelneale]

@jamadeo updated this to main - cli works still as expected, that is good to know. Do you think this should use the users default $SHELL and load it appropriately in fn shell functionality? (I believe can use interactive shell perhaps, but there is likely a reason we didn't, so your BASH_ENV approach may make sense, but do we want to assume bash?)

[michaelneale]

@jamadeo ah - I think I learned something, good find on BASH_ENV - yes that is idiomatic way, and I think it is fine for GUI to expect to load it from somewhere like you suggested. I now get there is interactive, login shells, and we don't load either (for GUI) but need an option to load something. Bash doesn't have a standard other than what you set BASH_ENV to be. however zsh, which is now I believe standard on macos, does:

My suggestion, not sure if harmful is a PR to this PR: #4702

An additional option, use the built in $SHELL value and delegate to that (so it isn't hard coded to bash). That allows it to load appropriately if zsh etc, fall back to bash. So bash requires that goose location, but zsh DOES read from ~/.zshenv which is the correct and idiomatic place to put non interactive and non login values (which work for GUI and cli the same). Bash will require the goose specific location as you found - just a thought given that zsh is now default on macos, so we don't have to source zshrc (nor should we!) but we can use that one.

thouights?

[michaelneale]

"I wonder if it's possible for the goose shell tool to start a single login shell using $SHELL, and spawn all other shells from that?" - yeah I think it is probably right to not use the login shell, or even interactive, as this is not what it was designed for. I am sure that is possible however, probably probably messy state wise...

[michaelneale]

@jamadeo I think this is ok thinking about it. The dependency on goose core crate if it is in issue we can pull out the get_config_dir to somewhere else if the direction of dependencies are wrong, but is likely ok.

main downside of this may be people needing to know to put a .bash_env in the goose config dir (or if using the other PR - .zshenv in their home dir). Would it make sense to have a .goose_env option in home dir or getting weird and kludgy now?