[Feature}:Add Scoped Path Filtering to git_log Built-in Tool

[Preciousuche]

Duplicate check

• I searched the existing open and closed issues and this is not a duplicate.

Problem

Currently, the built-in git_log tool only accepts count and workdir:

python
async def git_log(count: int = 10, workdir: str | None = None) -> str: ...
When an agent is investigating a bug, refactoring a module, or checking recent edits to a specific file or directory (e.g. src/agentos/channels/email.py or docs/), it has no way to scope the log query. It is forced to fetch the top N commits across the entire repository and hope the file was touched recently, which wastes tokens and context window space.

In contrast, git_diff already supports path: str | None = None.

Proposed behavior

1.Add an optional path: str | None = None parameter to git_log tool definition and documentation:
python
async def git_log(
count: int = 10,
path: str | None = None,
workdir: str | None = None,
) -> str:
2.Validate path using _reject_foreign_git_path(path) to maintain sandbox security boundaries.
Pass ["--", path] to git log when path is provided:
python
args = ["log", f"--max-count={count}", "--oneline", "--decorate"]
if path:
args += ["--", path]
3.Update @sandboxed argv_factory to include the path in the fingerprinted command.

Area

CLI

Alternatives considered

Agents running shell tool commands (git log -n 5 -- path/to/file): requires higher sandbox privilege grades and shell approval, whereas git_log is already safe and credential-redacted under git.read.

[andreapn]

Closing as wontfix. The gap is described accurately — git_log(count, workdir) has no path while git_diff does — but this is a new capability rather than a defect, and the bar for adding one here is that the existing surface is genuinely inadequate.

It is not. git_log returns correct results today; the cost of the missing parameter is that an agent investigating one file reads a few more commits than it needs. That is a token-efficiency argument, and a modest one — --oneline --decorate output is cheap, and the default is 10 commits.

Every parameter added to a built-in tool is also permanent surface: it goes into the tool schema every turn, it needs path validation, it needs the @sandboxed fingerprint updated, and it becomes another thing the approval ledger has to render correctly. #614 in this same batch is a live example of the argv fingerprint drifting out of sync with the function body once a tool takes a path.

On the alternative you considered: needing higher sandbox privilege for git log -- path via the shell tool is the system working as intended, not a workaround being blocked.

Closing this and PRs #641 and #624. Thanks to both of you for the patches — the reasoning in the issue was well argued, it just lands on the wrong side of "does this earn permanent tool surface".