Project-level config override in global ~/.config/goose

[rtalexk]

Please explain the motivation behind the feature request. Does this feature solve a particular problem you have been experiencing? What opportunities or use cases would be unlocked with this feature?

As an employee, I work with other developers. I want to use Goose, and fine tune it to my needs.

Goose provide different ways to achieve that, but I don't want to add goose specific configuration to work repositories.

So, I can create global settings, but those settings will apply to all my projects. I don't want that.

Describe the solution you'd like

I'd like to have a way to define project level config outside the project directory, maybe using overrides as:

GOOSE_MODEL: claude-sonnet-4-20250514
GOOSE_PROVIDER: claude-code
extensions:
  # extensions here

[project_1]
GOOSE_MODEL: other_model_123
extensions:
  # either merge or override extensions

[project_2]
# other overrides

Also I'd like to be able to have receipts outside the project that only apply for a given project.

Describe alternatives you've considered

I have thought about:

• Adding goose specific config files to .gitignore, but maybe I don't want my team know I'm using Goose.
• Create custom scripts to 'clean' the directory from Goose files before doing a commit, then bring them back after commit.
• Do the above manually, with the risk of committing Goose files.

Additional contextre.

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

[DOsinga]

you can do this using the GOOSE_PATH_ROOT environment variable. normally goose will store settings in .local/... but if you set that variable, you can get the whole config/logs/etc be somewhere else. we use it for testing, but you should be able to use it for projects too.

if you use hermit you can set it up such that you change the environment variable when you enter a folder

[rtalexk]

Interesting... I just installed Goose and from docs and some parts of the source code I understood that:

• ~/.config/ - user-specific configuration
  • config.yaml
  • history.txt - Command history across sessions
  • .goosehints - Global hints file for providing context to Goose
  • .gooseignore - Global ignore patterns
• ~/.local/share/ - user-specific data files
  • sessions/ - Session records
  • projects.json - project specific metadata (path, last instruction/session...)
• ~/.local/state/ - logs and state information

And GOOSE_PATH_ROOT changes that behavior, directories above are stored within the same path.

Hermit sounds a little bit overkill just to achieve that. It'd be cool if it is supported out of the box by Goose, but I understand that if that's not a feature more people need it doesn't make sense to invest time there.

For now, you gave me a great solution/idea to play with GOOSE_PATH_ROOT. I'm gonna use probably use mise or direnv to automatically change the env value when entering the project dir.

I found this other tool kakkun61/envar (GH Repo), but it was just created and doesn't give me enough confidence. 😅

[DOsinga]

ok, I'm going to close this for now. let us know how GOOSE_PATH_ROOT works out for you. @blackgirlbytes - not sure we've documented this - it might be worth a small post?

[blackgirlbytes]

thank you .we'll add it to our environment variables doc @DOsinga