Please explain the motivation behind the feature request.

Right now, if I run a command, the log mentioned are json events, and not completely intuitive to know that this is not all of the logs, and especially not anything about interactions like MCP

$ goose run -t "list the files in this directory"
starting session | provider: google model: gemini-2.0-flash
    logging to /Users/adriancole/.local/share/goose/sessions/20250408_102226.jsonl
    working directory: /Users/adriancole/oss/goose
--snip--

It took me a while to figure out that the real logs were in a completely different directory, and split across several files.

There are two directories logs go into, split across 4 files at the moment for a single run. There's no common part besides the date in the names to correlated them with, and the last log's purpose isn't clear by its name.

$ cd ~
$ find .local/share/goose/sessions .local/state/goose/logs
.local/share/goose/sessions
.local/share/goose/sessions/20250408_103600.jsonl
.local/state/goose/logs
.local/state/goose/logs/cli
.local/state/goose/logs/cli/2025-04-08
.local/state/goose/logs/cli/2025-04-08/20250408_103601-mcp-developer.log
.local/state/goose/logs/cli/2025-04-08/20250408_103600-mcp-computercontroller.log
.local/state/goose/logs/cli/2025-04-08/20250408_103603-20250408_103600.log

Describe the solution you'd like

All logs should go to the same directory, and that directory should be the one mentioned in the console.

Ideally no more than 2 log files to start with (session and real log): Facets for splitting things across date boundaries and multiple files should be an opt-in for power users not default. Consider learning curve as a part of devex design.

Describe alternatives you've considered

Alternative would be to also print the other log directory on startup, but that also emphasizes the confusion. Another way could be to change the first statement to "event log" or something to make it a bit more clear this is not the usual log file which things like tracing::info!("Starting MCP server") would go.

Additional context

Even goose (albeit with gemini) itself couldn't figure out where the logs are. While I think we can argue that engineers can eventually hunt this down, and when they find the source code it is well documented, let's consider goose. I would like to have goose troubleshoot itself and without a simple way for it to figure out how logging works, this is as impacted as end users new to the codebase would be.

• I have verified this does not duplicate an existing feature request