warm shell PATH lookup during session init

[baxen]

Category: improvement
User Impact: Shell commands become available sooner after a session loads because Goose starts warming the login-shell PATH earlier.
Problem: Loading a session paid the full cost of resolving the user's login-shell PATH before the model could make progress toward its first tool call. That extra setup time showed up as avoidable latency during session initialization.
Solution: Start the PATH resolution work when the developer shell tool is constructed and cache the eventual result for that session. This keeps the same PATH behavior while overlapping the expensive shell-profile warmup with the rest of session setup.

File changes

crates/goose/src/agents/platform_extensions/developer/shell.rs
Replaced the process-wide lazy PATH lookup with a session-scoped async cache that starts warming in the background during shell tool construction. The shell command path now awaits the warmed result on first use and reuses it for later calls in the same session.

1. Start Goose and load or create a session with the developer extension available.
2. Observe that session initialization no longer blocks on the login-shell PATH probe.
3. Make the first shell tool call in that session and confirm it still runs with the resolved login-shell PATH.
4. Repeat with a later session load and confirm the warmup runs as part of that new session's setup rather than being reused process-wide.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b424b624be

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Guard shell PATH warmup from missing Tokio runtime

ShellTool::new() is a synchronous constructor, but LoginPath::spawn() now calls tokio::task::spawn_blocking, which panics when no Tokio runtime is active. That turns client construction into a process crash instead of returning an error, so any non-async or pre-runtime caller of DeveloperClient::new() will fail hard. Please gate this with tokio::runtime::Handle::try_current() (and a fallback path) so construction remains safe outside async contexts.

Useful? React with 👍 / 👎.