误用 git push --force 且缺乏协作流程所致；应使用 git push --force-with-lease origin main，它通过比对本地缓存与远程真实状态防止覆盖他人提交，但需先执行 git fetch origin 以确保校验有效。
Git 本身没有“越权操作”概念——所谓越权，全是人配错权限、工具没拦住、流程没兜底导致的。 真正该收口的不是 Git 命令，而是「谁在什么上下文里能调用哪些命令」。下面几个关键点，直接对应日常踩坑现场。
git push --force 被误执行：别靠教育，靠 pre-push 钩子拦截
新人看到冲突就下意识敲 git push --force，不是手快，是根本不知道这个操作会覆盖他人提交。光靠文档或口头提醒没用，必须让命令在本地就失败。
- 在项目根目录加
.git/hooks/pre-push（需可执行），内容判断是否含--force或匹配保护分支（如main、develop） - 对
origin/main这类上游分支，强制要求使用git push --force-with-lease，它会检查远程 HEAD 是否变动，比裸--force安全得多 - IDE（如 VS Code）里默认禁用
--force按钮，但很多插件会绕过——得统一用core.hooksPath指向团队共享钩子目录，避免个人钩子被忽略
/menu/admin/tree 和 /menu/user/routes 必须拆开
后台菜单接口如果只用一个 endpoint 加 admin=true 参数区分，权限逻辑就会一路渗透到缓存键、数据库查询条件、甚至前端路由守卫里，最终变成“改一个字段要查五处 if”。这不是代码风格问题，是权限泄漏的温床。
git-log-tracker
下载
Git post-commit 钩子 + SQLite 提交索引工具。自动将每次提交的元数据（哈希值、作者、分支、仓库、主题）记录到本地 SQLite 数据库中，随后提供一个命令行接口（CLI），支持查询、列表展示、统计、删除和更新记录。 触发场景：管理 Git 钩子、跨仓库查询提交历史、定位某次提交所属的仓库、查看提交统计信息、将提交记录写入本地索引。 当用户提及“提交日志记录”、“提交索引”、“跨仓库查找提交”、“Git 钩子管理”，或希望以结构化方式查询其提交历史时（即使未明确指出该工具），请使
-
/menu/admin/tree接口必须走独立权限校验（比如只认role=admin），返回全量节点，且禁止任何缓存 -
/menu/user/routes接口必须按当前用户user_id+role查权限表，结果做树形组装，可缓存（key 含user_id和role） - 两个接口的 DTO 字段也要分离：管理端需要
is_hidden、sort、creator_id；运行时只需path、name、permission_code
Agent 工具调用层不设沙箱，等于给 LLM 发了 root 密码
你让 Agent 调用 git push 或 rm -rf，不是它想越权，是你没在工具注册时声明「能力边界」。LLM 输出不可控，但工具调用入口可以卡死。
- 所有工具函数注册前，必须显式标注
dangerous: true并绑定最小权限角色（例如role: ops_admin） - 执行前强制校验：
current_user.role是否包含该工具要求的角色，否则直接拒绝，不进 LLM 决策循环 - 高危命令（如
git push --force、pip install）必须走二次确认流程，且确认信息里带原始 prompt 片段，防止 Prompt 注入绕过
最常被忽略的一点：权限收口不是加一层 if 判断，而是让「越权路径」在抵达敏感操作前就断掉——钩子在本地、接口在网关、Agent 在工具层。三者不联动，任何一处松动都会让前面的努力白费。
