用repo管理的仓库，查git相关内容时会反复申请权限，不友好

[senluowx]

用repo管理的仓库，git信息在项目上一级 .repo 目录下，当前目录 .git 是个软链接，查询git信息的时候会反复申请权限，不友好

[argszero]

The repo-tool layout is the likely culprit. In a repo-managed tree, each project's .git entry is a symlink (or a gitfile) pointing into the shared repo metadata directory that lives one level above the project — so every git read physically resolves outside your DSH workspace root. When the sandboxed fs/subprocess containment sees git touching real paths outside the allowed workspace, it treats the access as out-of-bounds and raises an approval prompt — once per git invocation, hence "repeatedly asks for permission" on every status/log query.

Two things would confirm which layer is prompting (the fix differs):

1. The exact prompt text — does it name the tool (bash/shell), a plugin (e.g. a git-status plugin), or an fs/subprocess permission? That tells us whether the guard is command approval or path containment.
2. Whether plain git status in a normal (non-repo) workspace prompts at all. If it does not, the symlink escape is the discriminator: the sandbox resolves the .git target to a directory that is not under the workspace root, so the containment check fails on every read.

Practical workarounds that usually fix it today:

• Open the DSH session at the repo root (the directory that contains the dot-repo metadata folder) instead of inside a project subdirectory — then the git metadata lives inside the workspace and reads stay in-bounds.
• If the prompt offers an allowlist or "remember" option, allowing the specific metadata path for read-only plumbing (status/log/diff) is safe: git does not write through the .git link during read queries.
• If you are using a git-status style plugin, the same fix applies plugin-side: resolve the workspace git dir once (following the symlink) and treat it as the repo's git dir instead of re-checking containment on every call.

A proper core fix would classify "the workspace's own git dir, wherever the symlink resolves" as in-bounds for read-only plumbing. If you can paste the prompt text (paths redacted if you prefer), I can pinpoint the exact guard and say whether a core patch or a workaround is the right path.

[senluowx]

There's also a prompt in the repo root.
escalate sandbox to danger-full-access: Need git repo info which requires reading .git; sandbox has no backend