Codex CLI安全机制：沙盒策略与权限控制详解

【免费下载链接】codex 为开发者打造的聊天驱动开发工具，能运行代码、操作文件并迭代。 项目地址: https://gitcode.com/GitHub_Trending/codex31/codex

本文详细解析了Codex CLI的安全架构，重点介绍其三种沙盒模式（read-only、workspace-write、danger-full-access）和四种权限审批策略（untrusted、on-failure、on-request、never）。通过Landlock和Seatbelt等操作系统级安全技术，Codex CLI实现了精细化的权限控制和风险防范，为AI辅助编程提供了企业级的安全保障。

三种沙盒模式：read-only、workspace-write、danger-full-access

Codex CLI 提供了三种不同级别的沙盒安全模式，每种模式都针对特定的使用场景和安全需求进行了精心设计。这些沙盒模式通过 Landlock 和 seccomp 等 Linux 安全机制实现，确保 AI 代理在受控环境中执行操作。

read-only 模式：最高安全级别

read-only 模式是 Codex CLI 中最严格的沙盒策略，专为需要最高安全保证的场景设计。在此模式下，AI 代理只能执行读取操作，完全禁止任何形式的文件写入和网络访问。

核心特性

权限类型	允许状态	说明
文件读取	✅ 允许	可以读取整个文件系统的内容
文件写入	❌ 禁止	完全禁止任何文件修改操作
网络访问	❌ 禁止	禁止所有出站网络连接
系统调用	🔒 受限	仅允许安全的系统调用

技术实现

read-only 模式通过 Landlock 文件系统沙盒实现严格的权限控制：

pub fn new_read_only_policy() -> Self {
    SandboxPolicy::ReadOnly
}

pub fn has_full_disk_write_access(&self) -> bool {
    match self {
        SandboxPolicy::ReadOnly => false,
        // ... 其他模式
    }
}

Landlock 规则配置确保只能进行读取操作：

let access_ro = AccessFs::from_read(abi);
let ruleset = Ruleset::default()
    .handle_access(access_rw)?
    .create()?
    .add_rules(landlock::path_beneath_rules(&["/"], access_ro))?;

适用场景

• 代码审查和分析：安全地分析代码库而不修改任何文件
• 文档生成：读取项目文件并生成文档说明
• 安全审计：检查代码中的安全漏洞而不引入风险
• 只读查询：回答关于代码库的问题而不执行修改

workspace-write 模式：平衡安全与功能

workspace-write 模式在安全性和功能性之间取得了最佳平衡，是大多数开发场景的推荐选择。此模式允许在当前工作目录内进行写入操作，同时保持对其他系统区域的严格保护。

核心特性

权限类型	允许状态	说明
文件读取	✅ 允许	完整文件系统读取权限
工作区写入	✅ 允许	可在当前目录和临时目录写入
网络访问	⚡ 可配置	默认禁止，可通过配置启用
系统调用	🔒 受控	安全的系统调用子集

技术配置

workspace-write 模式提供灵活的配置选项：

SandboxPolicy::WorkspaceWrite {
    writable_roots: vec![],		    // 额外的可写根目录
    network_access: false,		    // 网络访问控制
    exclude_tmpdir_env_var: false,	    // 是否排除临时目录
    exclude_slash_tmp: false,	    // 是否排除 /tmp
}

默认配置提供安全的写入环境：

pub fn new_workspace_write_policy() -> Self {
    SandboxPolicy::WorkspaceWrite {
        writable_roots: vec![],
        network_access: false,
        exclude_tmpdir_env_var: false,
        exclude_slash_tmp: false,
    }
}

目录保护机制

workspace-write 模式包含智能的目录保护功能，防止意外修改关键文件：

受保护的子路径包括：

• .git/ - 版本控制元数据
• .hg/ - Mercurial 元数据
• .svn/ - Subversion 元数据
• 其他 VCS 相关目录

适用场景

• 日常开发：在版本控制的项目中进行代码修改
• 自动化重构：安全地执行代码重构操作
• 依赖管理：安装和更新项目依赖
• 测试执行：运行测试套件并生成测试报告

danger-full-access 模式：完全访问权限

danger-full-access 模式提供完全的系统访问权限，禁用所有沙盒保护机制。这是最高风险的模式，仅应在完全信任的环境中谨慎使用。

核心特性

权限类型	允许状态	说明
文件读取	✅ 完全	无限制的文件系统读取
文件写入	✅ 完全	无限制的文件系统写入
网络访问	✅ 完全	无限制的网络访问
系统调用	✅ 完全	所有系统调用可用

技术实现

danger-full-access 模式实质上禁用了所有安全限制：

pub fn has_full_disk_write_access(&self) -> bool {
    match self {
        SandboxPolicy::DangerFullAccess => true,
        SandboxPolicy::ReadOnly => false,
        SandboxPolicy::WorkspaceWrite { .. } => false,
    }
}

pub fn has_full_network_access(&self) -> bool {
    match self {
        SandboxPolicy::DangerFullAccess => true,
        // ... 其他模式
    }
}

安全警告

使用 danger-full-access 模式时需要特别注意：

1. 无沙盒保护：所有安全机制都被禁用
2. 系统级风险：AI 代理可以执行任意系统命令
3. 数据完整性：可能意外修改或删除重要文件
4. 网络安全：可能建立出站网络连接

适用场景

• 受控环境：在完全隔离的容器或虚拟机中
• 系统管理：需要执行系统级管理任务
• 紧急恢复：系统修复和恢复操作
• 开发测试：在测试环境中验证功能

模式比较与选择指南

下表总结了三种沙盒模式的主要区别：

特性	read-only	workspace-write	danger-full-access
文件读取	✅ 完全	✅ 完全	✅ 完全
文件写入	❌ 无	✅ 工作区	✅ 完全
网络访问	❌ 无	⚡ 可配置	✅ 完全
安全级别	🔒 最高	🛡️ 平衡	⚠️ 无保护
使用场景	审查/分析	日常开发	系统管理

配置示例

在 config.toml 中配置沙盒模式：

# 只读模式配置
approval_policy = "untrusted"
sandbox_mode = "read-only"

# 工作区写入模式配置  
approval_policy = "on-request"
sandbox_mode = "workspace-write"

# 工作区写入模式带网络访问
[sandbox_workspace_write]
network_access = true

# 危险模式配置
approval_policy = "never"
sandbox_mode = "danger-full-access"

命令行使用

通过命令行参数指定沙盒模式：

# 只读模式
codex --sandbox read-only --ask-for-approval on-request

# 工作区写入模式
codex --sandbox workspace-write --ask-for-approval on-failure

# 危险模式（不推荐）
codex --sandbox danger-full-access --ask-for-approval never

最佳实践建议

1. 默认使用 workspace-write：在版本控制的项目中提供最佳平衡
2. 新项目使用 read-only：首次探索未知代码库时优先安全
3. 谨慎使用危险模式：仅在完全信任的环境中使用
4. 结合批准策略：根据任务复杂度调整批准要求
5. 定期审查配置：确保沙盒设置符合当前安全需求

通过合理选择沙盒模式，开发者可以在享受 AI 辅助编程便利的同时，有效控制安全风险，保护系统和数据完整性。

权限审批策略：untrusted、on-failure、on-request、never

Codex CLI 提供了四种精细的权限审批策略，让开发者能够根据不同的使用场景和安全需求，精确控制AI代理执行命令时的权限审批行为。这些策略与沙盒策略协同工作，构成了Codex强大的安全防护体系。

策略概览

下表展示了四种权限审批策略的核心特性：

策略名称	用户交互	安全级别	适用场景
untrusted	高频率审批	最高	未知代码库、高风险环境
on-failure	失败时审批	中等	开发环境、信任代码库
on-request	按需审批	灵活	常规开发、平衡安全与效率
never	无审批	最低	CI/CD、批量处理、完全信任环境

untrusted（除非受信任）

untrusted策略采用最保守的安全策略，只有在命令被确认为"已知安全"且仅进行文件读取操作时才会自动批准执行。

安全命令识别机制

Codex通过is_known_safe_command()函数来判断命令是否安全，该函数维护了一个精心设计的白名单：

pub fn is_known_safe_command(command: &[String]) -> bool {
    if is_safe_to_call_with_exec(command) {
        return true;
    }
    
    // 支持bash -lc "..."形式的复合命令解析
    if let [bash, flag, script] = command
        && bash == "bash"
        && flag == "-lc"
        && let Some(tree) = try_parse_bash(script)
        && let Some(all_commands) = try_parse_word_only_commands_sequence(&tree, script)
        && !all_commands.is_empty()
        && all_commands
            .iter()
            .all(|cmd| is_safe_to_call_with_exec(cmd))
    {
        return true;
    }

    false
}

安全命令白名单

安全命令包括：

• 基础工具: cat, cd, echo, grep, ls, pwd, wc等
• Git操作: git status, git log, git diff, git show, git branch
• 受限find: 禁止使用-exec, -delete等危险选项
• 受限ripgrep: 禁止使用--pre, --hostname-bin等外部命令调用选项

on-failure（失败时审批）

on-failure策略采用"信任但验证"的方法，所有命令都会在沙盒中自动执行，只有在命令执行失败时才向用户请求审批。

执行流程

这种策略特别适合开发环境，因为它：

• 保持了开发流程的流畅性
• 在遇到问题时提供安全网
• 减少了不必要的用户交互中断

on-request（按需审批）

on-request是默认策略，将审批决策权交给AI模型。模型会根据命令的风险评估决定是否需要用户审批。

决策逻辑

pub fn assess_command_safety(
    command: &[String],
    approval_policy: AskForApproval,
    sandbox_policy: &SandboxPolicy,
    approved: &HashSet<Vec<String>>,
    with_escalated_permissions: bool,
) -> SafetyCheck {
    // 检查是否为已知安全命令或用户已批准命令
    if is_known_safe_command(command) || approved.contains(command) {
        return SafetyCheck::AutoApprove {
            sandbox_type: SandboxType::None,
        };
    }

    // 根据策略和沙盒设置评估安全性
    assess_safety_for_untrusted_command(approval_policy, sandbox_policy, with_escalated_permissions)
}

策略组合效果

on-request策略与不同沙盒模式的组合会产生不同的安全行为：

沙盒模式	网络访问	文件写入	用户审批频率
read-only	禁止	禁止	低
workspace-write	可选	工作区	中等
danger-full-access	允许	全系统	高

never（从不审批）

never策略完全禁用用户审批，所有命令都会根据当前沙盒策略自动执行或拒绝。

使用场景

这种策略适用于：

• CI/CD流水线: 自动化代码生成和测试
• 批量处理: 大规模代码重构或分析
• 受控环境: 完全信任的代码库和工具链

安全约束

即使在never模式下，Codex仍然强制执行沙盒限制：

pub fn assess_safety_for_untrusted_command(
    approval_policy: AskForApproval,
    sandbox_policy: &SandboxPolicy,
    with_escalated_permissions: bool,
) -> SafetyCheck {
    match (approval_policy, sandbox_policy) {
        // ...
        (Never, ReadOnly) | (Never, WorkspaceWrite { .. }) => {
            match get_platform_sandbox() {
                Some(sandbox_type) => SafetyCheck::AutoApprove { sandbox_type },
                None => SafetyCheck::Reject {
                    reason: "auto-rejected because command is not on trusted list".to_string(),
                }
            }
        }
        // ...
    }
}

配置示例

在config.toml中配置never策略：

# 完全自动化的只读模式
[profiles.ci_readonly]
approval_policy = "never"
sandbox_mode = "read-only"

# 工作区写入的自动化模式
[profiles.ci_workspace]
approval_policy = "never" 
sandbox_mode = "workspace-write"
network_access = false

# 危险的全访问模式（不推荐）
[profiles.danger_auto]
approval_policy = "never"
sandbox_mode = "danger-full-access"

策略选择指南

选择合适的权限审批策略需要综合考虑安全性、便利性和具体使用场景：

1. 安全性优先: 选择untrusted策略，最大程度减少风险
2. 开发效率: 选择on-failure或on-request，平衡安全与效率
3. 自动化场景: 选择never策略，配合适当的沙盒限制
4. 未知环境: 从untrusted开始，逐步放宽限制

每种策略都提供了独特的安全保障机制，开发者可以根据项目需求和个人偏好进行灵活配置，确保在享受AI辅助开发便利的同时，保持对系统安全的完全控制。

Landlock和Seatbelt安全技术实现

Codex CLI在Linux和macOS平台上分别采用Landlock与Seatbelt两种先进的安全沙盒技术，为AI驱动的代码执行提供精细化的权限控制。这两种技术从操作系统层面构建了强大的安全边界，确保AI助手在执行代码时不会对系统造成意外损害。

Landlock：Linux内核级文件系统沙盒

Landlock是Linux内核5.13版本引入的安全模块，允许非特权进程创建文件系统访问规则。Codex CLI通过codex-linux-sandbox二进制文件实现Landlock沙盒，其核心实现位于codex-rs/linux-sandbox/src/landlock.rs文件中。

Landlock沙盒架构

权限控制实现

Landlock沙盒通过ABI版本控制和规则集配置来实现精细的文件系统访问控制：

pub(crate) fn apply_sandbox_policy_to_current_thread(
    sandbox_policy: &SandboxPolicy,
    cwd: &Path,
) -> std::result::Result<(), SandboxErr> {
    // 网络访问控制
    if !sandbox_policy.has_full_network_access() {
        install_network_seccomp_filter_on_current_thread()?;
    }
    
    // 文件写入控制
    if !sandbox_policy.has_full_disk_write_access() {
        let writable_roots = sandbox_policy
            .get_writable_roots_with_cwd(cwd);
        apply_landlock_rules_to_current_thread(&writable_roots)?;
    }
    
    Ok(())
}

文件系统规则配置

Landlock规则集根据沙盒策略动态生成，支持多种访问权限级别：

权限级别	允许的操作	对应的Landlock规则
只读模式	文件读取	LANDLOCK_ACCESS_FS_READ_FILE
工作区写入	指定目录写入	LANDLOCK_ACCESS_FS_WRITE_FILE
完全访问	无限制写入	不应用Landlock限制

Seatbelt：macOS应用层沙盒

macOS平台使用Seatbelt沙盒技术，通过/usr/bin/sandbox-exec工具实现。Codex CLI的Seatbelt实现在codex-rs/core/src/seatbelt.rs中，采用声明式策略语言定义安全规则。

Seatbelt策略语言结构

Seatbelt策略使用LISP风格的语法，包含基础策略和动态生成的权限规则：

(version 1)
(allow default)
(deny network*)
(allow file-read*)
(allow file-write*
  (subpath (param "WRITABLE_ROOT_0"))
  (require-not (subpath (param "WRITABLE_ROOT_0_RO_0")))
)

动态策略生成机制

Codex CLI根据工作目录结构和Git仓库信息动态生成Seatbelt策略：

fn create_seatbelt_command_args(
    command: Vec<String>,
    sandbox_policy: &SandboxPolicy,
    cwd: &Path,
) -> Vec<String> {
    let (file_write_policy, extra_cli_args) = {
        if sandbox_policy.has_full_disk_write_access() {
            // 完全写入权限
            (r#"(allow file-write* (regex #"^/"))"#.to_string(), Vec::new())
        } else {
            // 受限写入权限
            let writable_roots = sandbox_policy.get_writable_roots_with_cwd(cwd);
            generate_restricted_write_policy(writable_roots)
        }
    };
    
    // 组合完整策略
    let full_policy = format!(
        "{}\n{}\n{}\n{}",
        MACOS_SEATBELT_BASE_POLICY,
        file_read_policy,
        file_write_policy,
        network_policy
    );
    
    // 构建执行参数
    let mut seatbelt_args = vec!["-p".to_string(), full_policy];
    seatbelt_args.extend(extra_cli_args);
    seatbelt_args
}

Git仓库敏感目录保护

Codex CLI特别关注Git仓库的安全性，自动将.git目录标记为只读，防止AI意外修改版本控制信息：

// 检测Git仓库并保护.git目录
if wr.root.join(".git").exists() {
    let git_param = format!("WRITABLE_ROOT_{}_RO_0", index);
    cli_args.push(format!("-D{git_param}={}", 
        wr.root.join(".git").canonicalize().unwrap().to_string_lossy()));
    
    // 生成排除.git目录的写入策略
    writable_folder_policies.push(format!(
        "(require-all (subpath (param \"{root_param}\")) \
         (require-not (subpath (param \"{git_param}\"))))"
    ));
}

网络访问控制

两种沙盒技术都实现了严格的网络访问控制，防止未经授权的网络连接：

seccomp网络过滤

在Linux平台上，使用seccomp BPF过滤器阻断网络相关系统调用：

fn install_network_seccomp_filter_on_current_thread() -> Result<(), SandboxErr> {
    let filter = SeccompFilter::new(
        vec![
            SeccompRule::new(
                vec![SeccompCondition::new(
                    0, 
                    SeccompCmpArgLen::Dword, 
                    SeccompCmpOp::Eq, 
                    libc::AF_INET as u64
                )?],
                SeccompAction::Errno(libc::EPERM as u32)
            )?,
            // 更多网络相关系统调用规则...
        ],
        SeccompAction::Allow,
        TargetArch::x86_64,
    )?;
    
    apply_filter(&filter)?;
    Ok(())
}

Seatbelt网络策略

在macOS上，使用Seatbelt策略语言限制网络访问：

(deny network-outbound)
(deny network-inbound)
(deny system-socket)

安全策略的层次化实现

Codex CLI的安全策略采用层次化设计，从宽松到严格提供多个安全级别：

安全级别	Landlock实现	Seatbelt实现	适用场景
只读模式	仅允许读取操作	(allow file-read*)	代码审查和分析
工作区写入	限制写入指定目录	动态生成写入策略	常规开发任务
完全访问	不应用Landlock	(allow file-write* (regex #"^/"))	高级系统操作

跨平台一致性保障

尽管底层技术不同，Codex CLI确保了跨平台的安全策略一致性：

1. 统一的策略接口：通过SandboxPolicy结构体抽象平台差异
2. 相同的行为语义：在不同平台上提供一致的安全保障级别
3. 透明的实现细节：用户无需关心底层技术差异

性能与安全平衡

Landlock和Seatbelt都在设计时考虑了性能影响：

• Landlock：内核级实现，性能开销极小
• Seatbelt：用户空间策略执行，策略编译后高效运行
• 惰性策略应用：只在需要时应用相应的安全限制

这两种技术的结合为Codex CLI提供了企业级的安全保障，使得开发者可以放心地使用AI助手进行代码编写和执行，而不必担心系统安全受到威胁。

安全最佳实践与风险防范指南

在Codex CLI的强大能力背后，安全始终是首要考虑因素。通过深入分析项目的安全架构和实施细节，我们可以总结出一系列最佳实践，帮助开发者在享受AI辅助编程便利的同时，最大限度地降低潜在风险。

沙盒策略配置最佳实践

Codex CLI提供了多层次的沙盒保护机制，正确的配置是确保安全的第一道防线：

# 推荐的安全配置示例
approval_policy = "on-request"  # 按需请求批准
sandbox_mode = "workspace-write"  # 工作区写入模式

# 网络访问控制（仅在必要时启用）
[sandbox_workspace_write]
network_access = false  # 默认禁用网络访问

# 自定义可写根目录
writable_roots = ["/safe/project/path"]
exclude_tmpdir_env_var = true  # 排除临时目录环境变量
exclude_slash_tmp = true  # 排除系统/tmp目录

配置策略说明：

• 版本控制项目：推荐使用 workspace-write 模式，允许在工作区内自由操作，但保护外部文件
• 非版本控制项目：使用 read-only 模式，所有写操作都需要明确批准
• 生产环境：始终启用 on-request 批准策略，避免自动执行高风险操作

命令执行安全评估流程

Codex CLI采用严格的安全评估机制来判断命令的执行方式：

权限提升风险管理

当Codex需要执行需要提升权限的操作时，系统会进行额外的安全检查：

// 权限提升安全检查逻辑
fn assess_safety_for_untrusted_command(
    approval_policy: AskForApproval,
    sandbox_policy: &SandboxPolicy,
    with_escalated_permissions: bool,  // 权限提升标志
) -> SafetyCheck {
    if with_escalated_permissions {
        // 权限提升操作总是需要用户批准
        SafetyCheck::AskUser
    } else {
        // 正常安全检查流程
        match get_platform_sandbox() {
            Some(sandbox_type) => SafetyCheck::AutoApprove { sandbox_type },
            None => SafetyCheck::AskUser,
        }
    }
}

权限提升操作包括：

• 修改系统级配置文件
• 安装系统级软件包
• 更改文件所有权或权限
• 访问受保护的系统资源

平台特定的沙盒实施

Codex CLI针对不同操作系统实现了专门的沙盒技术：

操作系统	沙盒技术	保护级别	限制
macOS	Seatbelt沙盒	高	文件系统访问、网络、进程间通信
Linux	Landlock + seccomp	中高	文件系统层次访问控制
Windows	暂无原生沙盒	低	依赖工作区限制

Linux Landlock配置示例：

// Landlock规则配置
let rules = landlock::Ruleset::new()
    .handle_access(landlock::AccessFs::from_bits_truncate(0x1f))
    .add_rule(landlock::Rule::path(
        &allowed_path,
        landlock::AccessFs::from_bits_truncate(0x1f),
    ))
    .unwrap()
    .restrict()
    .unwrap();

文件操作安全约束

Codex对文件操作实施了严格的范围检查，确保操作不会超出允许的边界：

fn is_write_patch_constrained_to_writable_paths(
    action: &ApplyPatchAction,
    sandbox_policy: &SandboxPolicy,
    cwd: &Path,
) -> bool {
    // 获取可写根目录
    let writable_roots = sandbox_policy.get_writable_roots_with_cwd(cwd);
    
    // 检查每个文件操作是否在允许范围内
    for (path, change) in action.changes() {
        if !is_path_writable(path, &writable_roots, cwd) {
            return false;  // 发现越权操作
        }
    }
    true  // 所有操作都在允许范围内
}

会话管理与凭证安全

Codex CLI提供了灵活的会话管理选项，确保认证信息的安全：

安全凭证管理实践：

• 使用环境变量 OPENAI_API_KEY 而非配置文件存储敏感密钥
• 定期轮换认证令牌
• 在headless环境中使用安全的凭证传输方式
• 避免在日志或输出中暴露认证信息

# 安全的凭证设置方式
export OPENAI_API_KEY="your-api-key-here"
codex  # 仅在当前会话有效

# 不推荐的永久存储方式
echo 'OPENAI_API_KEY="key"' >> ~/.bashrc  # 避免永久存储

网络访问控制策略

在网络访问方面，Codex提供了细粒度的控制选项：

# 网络访问配置
[sandbox_workspace_write]
network_access = false  # 默认禁用

# 允许特定域名的访问
allowed_domains = ["api.openai.com", "github.com"]

# DNS过滤设置
dns_filtering = true
block_known_malicious_domains = true

网络安全建议：

• 在沙盒模式下默认禁用网络访问
• 仅允许访问必要的API端点
• 实施DNS层面的恶意域名过滤
• 监控异常网络流量模式

审计日志与监控

启用详细的审计日志可以帮助追踪和分析Codex的行为：

# 启用详细日志
codex --verbose --log-level=debug

# 输出日志到文件
codex 2>&1 | tee codex-session.log

# 使用系统审计工具
sudo auditctl -a always,exit -F arch=b64 -S execve -F exe=/usr/local/bin/codex

监控指标：

• 文件操作次数和类型
• 网络请求的源和目标
• 命令执行的成功/失败率
• 用户批准和拒绝的统计

容器环境下的特殊考虑

在Docker或容器化环境中运行Codex时需要注意：

# Dockerfile安全配置示例
FROM ubuntu:22.04

# 使用非root用户
RUN useradd -m codexuser
USER codexuser

# 限制容器权限
RUN chmod 700 /home/codexuser

# 只挂载必要的卷
VOLUME /home/codexuser/project

# 设置资源限制
CMD ["codex", "--sandbox", "workspace-write", "--ask-for-approval", "on-request"]

容器安全实践：

• 使用非特权用户运行
• 限制文件系统挂载范围
• 设置适当的资源限制
• 定期更新基础镜像以获取安全补丁

通过遵循这些最佳实践，开发者可以充分利用Codex CLI的强大功能，同时确保开发环境的安全性和稳定性。记住，安全是一个持续的过程，需要根据具体的项目需求和环境特点进行调整和优化。

总结

Codex CLI通过多层次的安全机制构建了完善的防护体系：沙盒策略提供文件系统和网络访问控制，权限审批策略确保用户对关键操作的最终决策权，而Landlock和Seatbelt技术则从操作系统层面实现强制访问控制。开发者应根据具体场景选择合适的配置组合，遵循最小权限原则，在享受AI编程便利的同时确保系统安全。定期审查安全配置、启用审计日志监控，并遵循容器环境下的特殊安全考虑，能够最大化地降低潜在风险。

【免费下载链接】codex 为开发者打造的聊天驱动开发工具，能运行代码、操作文件并迭代。 项目地址: https://gitcode.com/GitHub_Trending/codex31/codex