Permission scanner misclassifies git -L arguments and shell command text as directory paths

[metawave]

Describe the bug

Copilot CLI incorrectly flags parts of a shell command as directory access candidates when running git log -L ... with a search expression that starts with /.

In my case, the permission prompt displayed a synthetic "path" composed of:

• the git log -L search expression
• a source file path
• trailing shell text such as && printf

This is not a real filesystem path. It appears the permission scanner is lexically collecting slash-prefixed command arguments and adjacent shell text, then presenting the result as an "Allow directory access" prompt.

Affected version

GitHub Copilot CLI 1.0.73

Steps to reproduce the behavior

Run a shell command shaped like this:

cd /REPO_ROOT && printf '%s\n' '---marker---' && git --no-pager log --oneline -L '/requestMatchers(HttpMethod).GET, "/some-route"/,+1:/project-module/src/main/java/com/example/security/SecurityConfig.java'

Then ask Copilot CLI to execute it under normal permissions.

Actual behavior

Copilot CLI shows an Allow directory access prompt and presents a "path" that is actually a mixture of:

• the -L search expression
• the Java source path
• trailing shell tokens such as && printf

Example of the misclassified candidate shape:

/requestMatchers(HttpMethod).GET, "/some-route"/,+1:/project-module/src/main/java/com/example/security/SecurityConfig.java && printf
/**
/requestMatchers(HttpMethod).GET,
/\*\*
/,+1:/project-module/src/main/java/com/example/security/SecurityConfig.java

This is not a valid directory path and should not be treated as one.

Expected behavior

Copilot CLI should not interpret git -L expressions or adjacent shell command text as filesystem paths.

If path scanning is needed, it should distinguish between:

• actual filesystem arguments
• regex/search expressions
• shell syntax and chained commands

Impact

This causes unnecessary permission prompts on normal investigation commands and interrupts the workflow.

Additional context

This looks related to other permission/path misclassification issues, especially cases where slash-prefixed strings or URL-like arguments are treated as local paths.