误用 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 在工具层。三者不联动，任何一处松动都会让前面的努力白费。