Skip to content

Goose cannot resolve locally-installed claude CLI due to restricted PATH #5915

@benzntech

Description

@benzntech

Describe the bug

Goose cannot resolve the claude CLI even though it is installed and works from my normal shell.

In Goose, when I configure a tool/command that runs claude, I get an error like:

could not resolve command 'claude': file does not exist

From the Goose logs, goosed is started with a restricted PATH that does not include my user-local install directory for claude. This means Goose cannot discover claude by name, even though it's available in my shell.

Goose PATH from main.log:

PATH: /Applications/Goose.app/Contents/Resources/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin

My claude CLI is installed at:

$HOME/.claude/local/claude

So claude is not resolvable when Goose tries to run it by command name.


To Reproduce
Steps to reproduce the behavior:

  1. Install the claude CLI locally under $HOME/.claude/local/claude (Anthropic's installer puts it there by default).
  2. In a terminal, verify it works:
    which claude
    # $HOME/.claude/local/claude
    
    $HOME/.claude/local/claude --help
  3. Open Goose Desktop and configure a tool/recipe that runs claude as a command, e.g.:
    • Command: claude
    • (Optionally) add arguments like chat or --help.
  4. Run that tool from Goose.

Observed behavior:
Goose returns an error similar to:

could not resolve command 'claude': file does not exist

If I instead configure Goose to use the absolute path:

$HOME/.claude/local/claude

the command works. This strongly suggests Goose's environment/PATH is not including the user-local bin directory where claude is installed.


Expected behavior

If a command is available on my user PATH in a normal shell and runs successfully there, Goose should be able to resolve and run it by name (e.g. claude) without requiring an absolute path or a global symlink into /usr/local/bin.

At minimum:

  • Goose should either inherit the user's shell PATH (or provide a way to configure it), or
  • Clearly document how the PATH for goosed is constructed and how to extend it for user-local binaries.

Screenshots

Image


Please provide the following information

  • OS & Arch: macOS 14.x+ (darwin arm64)
  • Interface: UI
  • Version: 1.15.0
  • Extensions enabled: Claude, Gemini
  • Provider & Model: Anthropic – claude-3.5-sonnet; Google – gemini-2.0-flash

Additional context

From ~/Library/Application Support/Goose/logs/main.log:

  • Goose starts goosed with:

    Starting goosed from: /Applications/Goose.app/Contents/Resources/bin/goosed on port 62557 in dir $HOME
    Spawn options:
      "cwd": "$HOME",
      "env": {
        "PATH": "/Applications/Goose.app/Contents/Resources/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin",
        "HOME": "$HOME",
        ...
      }
    
  • My claude CLI resides in $HOME/.claude/local/claude, which is not part of that PATH, so any Goose tool that calls claude by name fails with "file does not exist".

  • Workaround: Using the full absolute path $HOME/.claude/local/claude in the Goose tool configuration works, but requires hardcoding paths and is not portable across machines or users.

I can attach a diagnostics ZIP (generated via Settings → Help & feedback → Diagnostics) if that would help; please let me know if you want that bundle attached to this issue.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions