我把 Codex 装进了 Pi 5 Max：一块 Android 开发板，开始自己参与 AI 相框开发

还记得那句话吗——电脑是AI项目的"办公室"，但真实硬件才是它的"施工现场"。

这一次，我决定不再只在Mac上写代码、跑脚本、模拟设备效果。而是把整个开发环境，直接搬进一块

设备里。

说起来目标其实也挺直接的：

让这块Android开发板自己跑起Termux、Node.js、Python、Rust、Git，最后再装上

。

这样一来，它就不再只是一个被动显示内容的屏幕，而是可以直接参与AI相框项目开发、调试、排障和验证的设备端工作台。

◆为什么要这么折腾？

AI相框，听起来像是一个"展示照片"的产品。但真上手之后，你就会发现它更像一个小型的边缘智能终端：

• 要能管理本地图片、视频和文案素材。
• 要能生成播放列表。
• 要能运行展示页面或播放器。
• 要能排查网络、缓存、文件权限和设备状态。
• 以后还可能接入家庭相册、语音、传感器和Agent自动化。

如果所有调试都只发生在电脑上，等到上真机时，很多问题就会变成那句经典的"它在我电脑上明明可以"。

所以这次思路很清晰：把Codex带到设备上。

让AI不只在桌面开发环境里给建议，而是在真实硬件里参与排查和改代码。

◆第一步：确认我们操作的是哪一台设备

这一步看起来基础，但它决定了后面会不会误伤别的Android设备。

本次目标设备是：

ADB 地址：192.168.99.73:XXXX 
型号：orangepi5max 
产品：rk3588_t 
Android：13 
架构：arm64 
内核：Linux 5.10.157 
内存：约 8GB 
屏幕：1024x600 
GPU/OpenGL：OpenGL ES 3.2

本机ADB路径：

/Users/XXX/Library/Android/sdk/platform-tools/adb

同一局域网里还出现过另一台Android设备，所以所有ADB操作都明确带上-s 192.168.99.73:5555。在硬件开发里，这不是洁癖，是保命习惯。

◆第二步：给Android装上Termux

Pi 5 Max的Android系统里原本没有Termux，所以直接安装F-Droid官方签名版本。

版本信息：

包名：com.termux 
版本：0.118.3 
versionCode：1002 
架构：arm64-v8a

安装完成后，Termux Activity可以正常启动。也就是说，这块Android开发板已经有了一个接近Linux的终端入口。

接下来就可以在设备上准备开发工具链了。

◆第三步：把基础工具链补齐

Termux初始化后，先更新包，再安装基础工具：

pkg update -y 
pkg install -y curl tar coreutils 
pkg install -y nodejs-lts python rust git

最终验证到的版本是：

Node.js v24.15.0 
Python 3.13.13 
rustc 1.95.0 
cargo 1.95.0 
git version 2.54.0

这里有一个小插曲。

原本希望精确使用Node.js v24.14.1，但Termux当前可维护的LTS包安装到的是v24.15.0。中间也短暂试过当前版nodejs，会安装到v26.2.0。

最后选择nodejs-lts。做硬件端环境，稳定和可维护比"版本数字刚好一致"更重要。

◆第四步：安装Codex CLI

优先尝试官方standalone installer：

curl -fsSL https://chatgpt.com/codex/install.sh | CODEX_NON_INTERACTIVE=1 sh

安装器在Termux里识别为：

Linux (ARM64)

安装后得到：

Codex CLI 0.138.0 
安装路径：~/.local/bin/codex

把路径加到当前会话：

export PATH="$HOME/.local/bin:$PATH"

验证：

codex --version

输出：

codex-cli 0.138.0

到这里，事情已经成功了一半。但Android/Termux毕竟不是标准Linux发行版，后面还有一个平台识别的小坑。

◆第五步：补上npm方式，绕过Android平台识别问题

为了让Termux/Android下的可执行文件更稳，后续又补了一次npm安装：

npm install -g @openai/codex

问题来了：Termux会把平台识别成android，导致npm可选native包不会按普通Linux方式自动安装。

处理方式是强制补装官方Linux ARM64 native包：

npm install -g --force @openai/codex-linux-arm64@npm:@openai/codex@0.138.0-linux-arm64

最终验证路径：

/data/data/com.termux/files/usr/bin/codex

最终版本：

codex-cli 0.138.0

这一步的意义是：以后在设备端调试，不用担心某次PATH或native包选择导致命令不可用。

◆第六步：登录认证，遇到真正的坑

原计划使用设备码登录：

codex login --device-auth

但在Pi 5 Max Termux中多次失败，错误指向设备码接口请求失败：

Error logging in with device code: error sending request for url (https://auth.openai.com/api/accounts/deviceauth/usercode)

尝试过CA证书路径、网络连通性和DNS方向排查后，设备码登录仍没有成功。

最后采用了本机已有Codex登录缓存迁移方式：

源文件：/Users/XXX/.codex/auth.json 
目标位置：/data/data/com.termux/files/home/.codex/auth.json

权限设置：

chmod 700 ~/.codex 
chmod 600 ~/.codex/auth.json

这里必须强调：这不是通用首选方案。通用首选仍然是设备码登录。只有在设备码网络请求失败，并且本机已经有可信Codex登录状态时，才考虑迁移认证缓存。认证文件不能写进文档、Git仓库、聊天记录或任何项目文件。

◆第七步：验证Codex已经在设备端跑起来

认证完成后，在Pi 5 Max Termux中执行：

command -v codex 
codex --version 
codex doctor --summary 
codex debug models

关键结果：

• codex命令可以被找到。
• 版本为codex-cli 0.138.0。
• codex debug models能返回模型能力JSON。
• 返回内容包含上下文窗口、输入模态、搜索工具支持等字段。

这说明Codex CLI已经能读取认证，并且可以访问OpenAI服务。

换句话说，Pi 5 Max不再只是一个"被电脑控制的屏幕"，它已经具备了设备端AI开发节点的雏形。

◆接下来，AI相框可以怎么跑？

后续可以在Pi 5 Max上建立一个设备端项目目录：

mkdir -p ~/ai-frame 
cd ~/ai-frame 
codex "检查当前目录，并帮我规划 AI 相框的设备端项目结构"

建议的目录结构是：

~/ai-frame/
   content/        # 图片、视频、文案、展示素材
   scripts/        # 拉取内容、生成播放列表、清理缓存等脚本
   renderer/       # 相框页面或播放器逻辑
   agent/          # Codex/LLM 驱动的决策逻辑
   logs/           # 运行日志
   config/         # API、设备、显示、网络配置，不提交密钥

第一阶段不用一下子做得很复杂。最小闭环可以是：

1. 设备启动后进入一个固定展示页面。
2. 本地content/目录里的图片可以轮播。
3. 用脚本生成playlist.json。
4. 用Codex CLI辅助修改脚本和排查运行错误。
5. 再逐步接入联网内容、家庭相册、语音或传感器输入。

这样做的好处是，每一步都发生在真实硬件上。不是先幻想一个完整系统，而是让设备自己先跑起来。

◆这次最值得记住的几个坑

第一，ADB网络连接可能不稳定。安装过程中Pi 5 Max一度从ADB设备列表里消失，ping和ARP也出现过异常。恢复后，192.168.99.73可以ping通，但ADB TCP5555一开始仍然Connection refused。

所以不要省略确认步骤：

adb connect 192.168.99.73:5555 
adb devices -l

第二，Termux不是标准Linux。它足够强，但在平台识别、native包选择、路径权限和登录请求上，都会有Android自己的差异。

第三，认证文件必须谨慎处理。不要把auth.json、API Key、Cookie或token写入项目，也不要为了"方便复现"把它们贴到文档里。

第四，真实设备开发一定要带设备ID。多台Android设备同时在线时，ADB命令不带-s就是在和运气合作。

◆结论：这块屏幕开始变得不一样了

这次的结果是：

• Pi 5 Max Android可通过ADB访问。
• Termux已安装。
• Node.js、Python、Rust、Git已安装。
• Codex CLI已安装。
• Codex CLI版本为0.138.0。
• Codex CLI已完成认证。
• codex debug models已能返回OpenAI模型能力信息。

它还不是一个完整的AI相框产品。但它已经从"一块能显示内容的Android板子"，变成了"可以在设备端开发、调试、验证AI相框逻辑的边缘节点"。

这一步很关键。因为真正的AI硬件产品，不是PPT里的能力堆叠，而是一个个能在真实设备上跑通的小闭环。

电脑负责规划，设备负责验证。当Codex也能进入设备现场，AI相框项目就开始离真实产品更近了一点。