What causes "Codex CLI 没有执行权限：{executable}" in BigPizzaV3/CodexPlusPlus?

Run `chmod +x ` to add the execute bit and retry

Codex CLI 没有执行权限：

Error message

Codex CLI 没有执行权限：{executable}

What it means

On Unix, validate_codex_executable checks the file mode bits; if none of the execute bits (0o111) are set on the Codex CLI binary, the library throws this error before spawn. This prevents a confusing spawn PermissionDenied later by naming the real cause: the file exists but is not executable.

Solutions

Run `chmod +x <path-to-codex>` to add the execute bit and retry
Reinstall via the package manager (npm i -g @openai/codex or the installer) so permissions are set correctly
If on a filesystem that strips modes, move the binary to a local filesystem (e.g. ~/bin)

Example fix

// shell, before
-rw-r--r-- codex
// after
chmod +x /usr/local/bin/codex

Defensive patterns

Strategy: validation

Validate before calling

#[cfg(unix)]
fn has_exec_bit(path: &str) -> bool {
    use std::os::unix::fs::PermissionsExt;
    std::fs::metadata(path)
        .map(|m| m.permissions().mode() & 0o111 != 0)
        .unwrap_or(false)
}

Try / catch

match CodexAppServer::start(config).await {
    Err(e) if e.to_string().contains("没有执行权限") => {
        eprintln!("chmod +x {} and retry", config.executable);
    }
    r => r?,
}

Prevention

chmod +x after extracting binaries from archives
Install via a package manager (npm/homebrew) so permissions are set automatically
Check with `ls -l` that the binary has x bits before configuring it
Avoid storing binaries on filesystems that drop permission bits

When it happens

Trigger: CodexAppServer::start with executable pointing to an existing regular file whose permission bits lack any x bit — e.g. a binary restored from a zip/tar without preserving modes, or copied with cp -r after a restrictive umask.

Common situations: Extracted codex binary from an archive (modes lost), mounted a volume with noexec... actually with restrictive umask, downloaded binary without chmod +x, files synced via cloud tools that drop permissions.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Related errors

AI-assisted analysis of BigPizzaV3/CodexPlusPlus@b1ed92e5e4 (2026-09-19). Data as JSON: /api/errors/9fc03d0f269ffcff. Report an issue: GitHub.

Appendix: source

Thrown at crates/codex-plus-core/src/connect/app_server.rs:88

        bail!(
            "Codex CLI 路径不存在：{executable}\n请填 Codex CLI 可执行文件的完整路径。\
             macOS 桌面版通常在 /Applications/ChatGPT.app/Contents/Resources/codex；\
             npm 全局安装可用 `which codex` / `where codex` 查看。"
        );
    }
    if path.is_dir() {
        bail!(
            "Codex CLI 路径指向的是目录而不是可执行文件：{executable}\n\
             请去掉结尾的路径分隔符，或补上具体的可执行文件名。"
        );
    }
    #[cfg(unix)]
    {
        use std::os::unix::fs::PermissionsExt;
        if let Ok(metadata) = std::fs::metadata(path)
            && metadata.permissions().mode() & 0o111 == 0
        {
            bail!("Codex CLI 没有执行权限：{executable}");
        }
    }
    Ok(())
}

impl CodexAppServer {
    pub async fn start(config: AppServerConfig) -> anyhow::Result<Self> {
        let executable = if config.executable.trim().is_empty() {
            "codex"
        } else {
            config.executable.trim()
        };
        validate_codex_executable(executable)?;
        let mut command = Command::new(executable);
        command
            .arg("app-server")
            .current_dir(&config.work_dir)
            .stdin(Stdio::piped())

View on GitHub (pinned to b1ed92e5e4)