dcg allow-once临时授权码详解24小时自动过期的单次放行机制【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guarddcgDestructive Command Guard是一款面向 AI 编码代理的高性能命令守卫 Hook它能在git reset --hard、rm -rf ./src这类高危命令执行前将其拦截。而当某条命令确实需要放行时dcg 的allow-once 临时授权码机制就派上用场了每次拦截都会生成一个 6 位数字授权码你可以用它为这条命令开一张临时通行证——只匹配这条命令、只限定当前项目、24 小时后自动过期无需永久修改安全策略。什么是 allow-once误报拦截的安全逃生门AI 代理偶尔会被 dcg 拦截一条你本来就想执行的命令。传统做法是去配置里加白名单但这等于永久削弱防线。allow-once 的设计思路是最小化例外✅ 只对被拦截的那条命令原文生效多一个空格都不匹配✅ 只在当前项目目录范围内有效✅24 小时后自动失效且时长不可配置✅ 每次放行都有日志可审计这套机制的详细用法可参考项目文档 docs/allow-once-usage.md其底层设计则记录在 docs/design-allow-once-short-code.md 中。三步上手从拦截到放行的最短路径第 1 步命令被拦截时拿到 6 位授权码当 dcg 拦截命令时终端输出的第一行就会带有授权码ALLOW-24H CODE: [123456] | run: dcg allow-once 123456 Tip: dcg explain git reset --hard HEAD授权码由被拦截命令、当前目录和时间戳共同计算得出实现见 src/pending_exceptions.rs所以同一条命令在不同时间被拦截拿到的码也不同。第 2 步运行 allow-once 完成授权把码交还回 CLI 即可dcg allow-once 123456一条命令无需编辑任何配置文件。如果只是想先看看会生成什么例外、而不真正写入可以加--dry-run预览。第 3 步放行生效24 小时后自动清零授权成功后dcg 会放行该命令但这条例外最多存活 24 小时。到期后 dcg 会在下次运行时自动清理prune过期记录并写入日志你的安全策略会自己回到原位。四大安全边界为什么它不会失控allow-once 虽然方便但被严格限制在四个维度之内边界规则 命令匹配只匹配被拦截时的命令原文参数、空格变化都会失效 目录作用域在 git 仓库内 → 整个项目范围生效仓库外 → 仅当前目录生效自动判定不可覆盖⏰ 过期时间固定 24 小时不可配置️ 优先级可覆盖规则包拦截但不能覆盖你在配置文件中显式写死的 blocklist除非用--force作用域判定逻辑可以在 src/pending_exceptions.rs 的matches_scope方法中看到Project范围用前缀匹配Cwd范围要求目录完全相等。常用参数按需收紧放行策略参数作用适用场景--single-use一次性例外用掉即消耗只想放行这一次最推荐--force覆盖配置文件中的显式 blocklist你自己写死的拦截也要临时绕开--dry-run只预览、不写入例外不确定影响范围时先试试--yes跳过交互确认脚本/非交互环境--pick N/--hash HASH按序号或完整哈希消歧多个命令撞了同一个短码官方最佳实践建议一次性操作优先用--single-use并且放行前先用dcg explain command弄清它为什么被拦。授权码管理查询、吊销与清理除了发码dcg 还提供了一组管理子命令CLI 定义见 src/cli.rsdcg allow-once list # 查看待用码与生效中的例外默认脱敏显示 dcg allow-once list --show-raw # 显示原始命令文本仅可信环境使用 dcg allow-once revoke 123456 # 吊销指定码或例外 dcg allow-once clear --all # 清空全部记录所有记录都以 JSONL 形式存放在~/.config/dcg/下的pending_exceptions.jsonl待用码和allow_once.jsonl生效例外两个文件中。默认展示会对 token、密码等敏感串做脱敏--show-raw才会显示原文请只在可信环境使用。进阶加固用 HMAC 防止授权码被伪造默认情况下授权码是本地短哈希攻击者理论上可能试探出有效码。如果你希望更强保证可以设置环境变量export DCG_ALLOW_ONCE_SECRET你的密钥开启后短码改用HMAC-SHA256生成——没有密钥就无法伪造合法码。注意一个取舍密钥一旦更换旧码全部失效需要重新运行被拦截的命令生成新码。常见问题速查Code not found or expired码已过期超过 24 小时或被吊销重新运行那条被拦截的命令即可生成新码。Code matches multiple entries短码发生了碰撞用--pick 1按序号选择或--hash 0123...按完整哈希精确指定。Cannot override config blocklist without --force这条命令被你显式写进了 blocklist确认无误后加--force重试。小结dcg 的 allow-once 临时授权码把临时放行做成了有边界、可审计、自动过期的一次性机制6 位数字、一条命令、24 小时寿命。它让你在享受 AI 编码代理效率的同时不必为一次例外而长期敞开防线——这大概就是安全默认与使用便利之间最优雅的平衡点。【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 dcg allow-once临时授权码详解：24小时自动过期的单次放行机制
dcg allow-once临时授权码详解24小时自动过期的单次放行机制【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guarddcgDestructive Command Guard是一款面向 AI 编码代理的高性能命令守卫 Hook它能在git reset --hard、rm -rf ./src这类高危命令执行前将其拦截。而当某条命令确实需要放行时dcg 的allow-once 临时授权码机制就派上用场了每次拦截都会生成一个 6 位数字授权码你可以用它为这条命令开一张临时通行证——只匹配这条命令、只限定当前项目、24 小时后自动过期无需永久修改安全策略。什么是 allow-once误报拦截的安全逃生门AI 代理偶尔会被 dcg 拦截一条你本来就想执行的命令。传统做法是去配置里加白名单但这等于永久削弱防线。allow-once 的设计思路是最小化例外✅ 只对被拦截的那条命令原文生效多一个空格都不匹配✅ 只在当前项目目录范围内有效✅24 小时后自动失效且时长不可配置✅ 每次放行都有日志可审计这套机制的详细用法可参考项目文档 docs/allow-once-usage.md其底层设计则记录在 docs/design-allow-once-short-code.md 中。三步上手从拦截到放行的最短路径第 1 步命令被拦截时拿到 6 位授权码当 dcg 拦截命令时终端输出的第一行就会带有授权码ALLOW-24H CODE: [123456] | run: dcg allow-once 123456 Tip: dcg explain git reset --hard HEAD授权码由被拦截命令、当前目录和时间戳共同计算得出实现见 src/pending_exceptions.rs所以同一条命令在不同时间被拦截拿到的码也不同。第 2 步运行 allow-once 完成授权把码交还回 CLI 即可dcg allow-once 123456一条命令无需编辑任何配置文件。如果只是想先看看会生成什么例外、而不真正写入可以加--dry-run预览。第 3 步放行生效24 小时后自动清零授权成功后dcg 会放行该命令但这条例外最多存活 24 小时。到期后 dcg 会在下次运行时自动清理prune过期记录并写入日志你的安全策略会自己回到原位。四大安全边界为什么它不会失控allow-once 虽然方便但被严格限制在四个维度之内边界规则 命令匹配只匹配被拦截时的命令原文参数、空格变化都会失效 目录作用域在 git 仓库内 → 整个项目范围生效仓库外 → 仅当前目录生效自动判定不可覆盖⏰ 过期时间固定 24 小时不可配置️ 优先级可覆盖规则包拦截但不能覆盖你在配置文件中显式写死的 blocklist除非用--force作用域判定逻辑可以在 src/pending_exceptions.rs 的matches_scope方法中看到Project范围用前缀匹配Cwd范围要求目录完全相等。常用参数按需收紧放行策略参数作用适用场景--single-use一次性例外用掉即消耗只想放行这一次最推荐--force覆盖配置文件中的显式 blocklist你自己写死的拦截也要临时绕开--dry-run只预览、不写入例外不确定影响范围时先试试--yes跳过交互确认脚本/非交互环境--pick N/--hash HASH按序号或完整哈希消歧多个命令撞了同一个短码官方最佳实践建议一次性操作优先用--single-use并且放行前先用dcg explain command弄清它为什么被拦。授权码管理查询、吊销与清理除了发码dcg 还提供了一组管理子命令CLI 定义见 src/cli.rsdcg allow-once list # 查看待用码与生效中的例外默认脱敏显示 dcg allow-once list --show-raw # 显示原始命令文本仅可信环境使用 dcg allow-once revoke 123456 # 吊销指定码或例外 dcg allow-once clear --all # 清空全部记录所有记录都以 JSONL 形式存放在~/.config/dcg/下的pending_exceptions.jsonl待用码和allow_once.jsonl生效例外两个文件中。默认展示会对 token、密码等敏感串做脱敏--show-raw才会显示原文请只在可信环境使用。进阶加固用 HMAC 防止授权码被伪造默认情况下授权码是本地短哈希攻击者理论上可能试探出有效码。如果你希望更强保证可以设置环境变量export DCG_ALLOW_ONCE_SECRET你的密钥开启后短码改用HMAC-SHA256生成——没有密钥就无法伪造合法码。注意一个取舍密钥一旦更换旧码全部失效需要重新运行被拦截的命令生成新码。常见问题速查Code not found or expired码已过期超过 24 小时或被吊销重新运行那条被拦截的命令即可生成新码。Code matches multiple entries短码发生了碰撞用--pick 1按序号选择或--hash 0123...按完整哈希精确指定。Cannot override config blocklist without --force这条命令被你显式写进了 blocklist确认无误后加--force重试。小结dcg 的 allow-once 临时授权码把临时放行做成了有边界、可审计、自动过期的一次性机制6 位数字、一条命令、24 小时寿命。它让你在享受 AI 编码代理效率的同时不必为一次例外而长期敞开防线——这大概就是安全默认与使用便利之间最优雅的平衡点。【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guard创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考