gemini-cli - 💡(How to fix) Fix bug(core): `tools.callCommand` still treats shell command as literal executable path [1 pull requests]

Summary

tools.callCommand is documented as a custom shell command, but discovered tool execution still treats the configured string as a literal executable path. As a result, common configurations like python3 script.py --call can discover tools successfully and then fail at execution time with ENOENT.

This is effectively a re-report of #19783 with fresh confirmation on current main, because that issue was auto-closed as stale and the behavior still appears unresolved.

Current evidence

At commit a00d03efc62de08274619cf7da96569ae51ecbf3:

• The settings schema documents tools.callCommand as a custom shell command in packages/cli/src/config/settingsSchema.ts#L1729-L1738.
• DiscoveredToolInvocation.execute() still takes getToolCallCommand() as a single string and passes it to spawn() as the executable, with only the tool name as argv in packages/core/src/tools/tool-registry.ts#L61-L95.
• The discovery path behaves differently: command discovery parsing uses shell-quote, while the discovered tool description still says execution will run ${callCommand} ${originalName} in packages/core/src/tools/tool-registry.ts#L182-L190.

Reproduction

Configure custom tools like this:

{
  "tools": {
    "discoveryCommand": "python3 script.py --discover",
    "callCommand": "python3 script.py --call"
  }
}

Expected:

• discovery works
• execution invokes python3 with script.py --call <toolName>

Actual:

• discovery works
• execution can fail because callCommand is treated as a literal executable path instead of a parsed command with arguments

Why this is likely still a bug

There is already prior history pointing at the same root cause:

• #19783 reported the inconsistency between discoveryCommand and callCommand
• PR #19935 proposed parsing callCommand with shell-quote to match discovery, but it was closed without merging

The current code still appears to match the pre-fix behavior.

Possible fix

Parse tools.callCommand consistently with tools.discoveryCommand, then append the discovered tool name to the parsed argv before spawning the subprocess.