一次安装
在组织上安装并选择仓库。将安装关联到一个 Codna 账户。管理员可以在账户页关闭自动修复。
企业版
你的密钥
带上模型密钥，Codna 就直接调用你的提供商。密钥存在操作系统钥匙串中，从不打印。或者使用托管额度。
每个 PR 都自我说明
审查发布带有严重性和置信度的发现以及明确的结论。修复 PR 说明 issue、根因、符号和置信度。由你合并。
Server 许可
按计算单元授权，在你自己的生产服务器上运行 Codna。你的硬件，你的网络，你的密钥。
运行方式
选择 Codna 在哪里运行。
Codna 在任何地方都运行同样的命令。选择符合你控制要求的方式；准备好后再添加另一种。
在你的机器上
CLI 和 MCP 服务器用你自己的密钥在本地运行。理解离线进行，不消耗 token。无需运维服务器。
在你的 CI 中
thyn-ai/codna-action@v1 在你自己的 runner 上用你自己的密钥运行 fix、review 或 secure。它打开 pull request，从不合并。
GitHub App
由 Codna 托管。审查每一个 pull request，从标签、评论和红色检查打开修复，使用托管额度或你的密钥。
Server 许可
按计算单元授权，在你自己的生产服务器上运行 Codna。激活与条款请联系我们。
推广
分阶段采用。
你不必在第一天就把钥匙交给智能体。随着信任建立再扩大范围。Codna 在任何阶段都从不合并。
1
只做审查
安装 App。Codna 以只读方式审查每一个 pull request，没有写令牌，也没有 shell。发现带有严重性、类别和置信度。不改动任何代码。
2
由你批准的修复 PR
允许具有写权限的协作者在某个发现下回复 @codna fix，或给 issue 打上 codna-fix 标签。每个 pull request 都说明 issue、根因、符号和置信度。你的工程师审查并合并。
3
红色检查打开修复
让失败的检查套件触发修复。Codna 先对故障分诊，所以基础设施故障不花任何成本，并且每个 pull request head 每天只打开一次修复。管理员随时可以关闭自动修复。
控制手段
今天真实存在的。
Codna 是一组技术行为，而不是认证。以下是你从用户这一侧就能验证的内容。
什么会离开你的机器
Triage、仓库地图和回忆离线运行。只有证据包或 diff 会通过你的密钥送达模型提供商。审查期间，除非出口为 fail-closed，Codna 还会向 npm 和 PyPI 核对依赖声明。
每个结果都自我说明
审查发布带有严重性、类别和置信度的发现，并以明确的结论结束。修复 PR 说明 issue、根因、符号和置信度。所有输出中的密钥都会被脱敏，且无法关闭。
最小权限
App 为每个任务使用短期、仅限该仓库的令牌。审查智能体不持有写令牌。写令牌会从运行仓库代码的环境中清除。@codna fix 需要请求者具有写权限。
你的密钥，你的提供商
带上 Anthropic、OpenAI、Google Gemini、Groq、Mistral、OpenRouter 或 xAI 的密钥。Codna 直接调用你的提供商。除非你选择加入，你的代码不会被用于训练模型。
常见问题
可以。CLI 和 GitHub Action 运行在你的机器上。理解在本地以零 token 运行。只有证据包或 diff 会通过你的密钥送达模型提供商。托管的 GitHub App 是可选的。
不必。使用 CLI 和 Action 时，密钥留在你的钥匙串或 CI 密钥中，Codna 直接调用你的提供商。使用 App 时，你可以使用托管额度，或在账户页添加自己的密钥。
在 codna.yaml 中把 privacy.egress 设为 fail-closed。此后 Codna 只在能于内核级拒绝其网络访问时才运行你的测试，并在审查期间不做任何注册表查询。密钥脱敏始终开启。写令牌会从运行仓库代码的环境中清除。
除非你选择加入，你的代码不会被用于训练模型。见隐私政策。
每个任务使用短期、仅限该仓库的令牌。审查智能体不持有写令牌。@codna fix 需要请求者具有写权限。管理员可以为组织关闭自动修复。每个提交都由 codna-ai[bot] 署名。
Codna 以 CLI、MCP 服务器、GitHub Action 和 GitHub App 提供，团队可以一次采用一种方式。Codna 从不合并：你的分支规则、必需检查和审查者始终掌控一切。
