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

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.

提供された shell コマンドで権限プロンプトを再現し、git -L の引数と連結された shell テキストからパス候補を収集する CLI 権限スキャナーを追跡します。候補リストを実際のファイルシステム引数と比較し、検索式と末尾の shell トークンによってディレクトリへのアクセスを求めるプロンプトが発生しなくなったことを確認します。