引言：Agent Runtime纪元与Harness工程的范式转移

       大语言模型的技术演进正在经历一次深刻的中心转移。在大模型发展的早期阶段，产业界的竞争焦点长期局限于参数规模、上下文窗口长度以及各类静态基准测试中的得分表现。然而，当大模型尝试从单纯的对话交互走向能够自主规划、调用工具并执行多步复杂任务的智能体（Agent）形态时，单纯依赖模型端推理能力的工程局限性迅速暴露1。在真实生产环境中，智能体系统频繁遭遇任务规划中断、状态无故丢失、敏感凭证泄露以及非预期破坏性副作用等系统性工程风险3。这一现实表明，2026年人工智能工程化的核心课题，已从底层的模型推理演化为围绕模型构建的驾驭与执行系统，即 Harness 工程3。

       Harness，或称智能体运行时（Agent Runtime），是连接高阶推理模型与物理或数字执行环境的枢纽2。它负责接管智能体的生命周期，包括上下文动态感知、工具调度分发、安全沙盒隔离、运行状态持久化、人类干预审批以及容错恢复等关键工程环节4。当前全球大模型领军机构在此领域的布局，展现出两条截然不同乃至背道而驰的技术哲学与战略路线1。
DeepSeek选择“向左”，推出了基于Cordis元框架的开源项目DeepSeek Harness（DSH）3。DSH主打“一切皆插件”的技术范式，以极具学术色彩的形式化理论为支撑，试图通过解构特权内核，打造一个彻底去中心化、可高度定制与动态热重载的智能体操作系统元框架5。与此形成鲜明对照的是，OpenAI选择“向右”，不仅升级了 Agents SDK，更将基于 Rust 构建的 Codex Harness 核心仓库（openai/codex）采用 Apache-2.0 协议彻底开源1。OpenAI 遵循工业级生产落地的确定性导向，建立了从单次脚本级任务到端到端产品集成的三阶段“产品化 Harness”分层治理体系，通过控制平面与计算平面的物理分离、持久化状态引擎以及高隔离度的容器沙盒，专注于解决长时运行智能体在企业级与消费级应用中的安全性、容错性与产品接入效率3。

       这种“向左”与“向右”的分野，绝非单纯的技术路线之争，而是“学术第一性原理驱动的解构主义”与“工业场景需求倒逼的工程确定性”之间的深刻博弈1。对这两种范式进行深度的技术架构解构与五级开源战略剖析，不仅能够揭示当前全球智能体基础设施的演进趋势，更能够以批判性视角厘清中国开源团队在治理理念与产业认知上的短板，为中国大模型生态走向全球高阶竞技舞台提供清晰的策略指引3。

架构解构：DSH与OpenAI Harness的技术范式双轨对决

DeepSeek Harness：以Cordis元框架为核心的极致扩展主义

       DSH在技术架构设计上展现出高度抽象的理论自觉。其底层依赖于DeepSeek团队研发的Cordis元框架，该框架的形式化数学基础源自学术论文《A Programming Paradigm for Spatiotemporal Composability》5。DSH打破了传统智能体框架将“调度循环（Agent Loop）”与“核心上下文”作为特权内核的惯例，把模型适配器、工具注册表、执行沙盒、会话日志、调度逻辑乃至前端交互界面，完全退化为平权的Cordis插件5。

架构层级	核心构件与工程机制	理论与代码映射	战略设计意图
理论底座	形式化时空可组合性理论3	论文定理61（恢复精确性）、定理63（依赖排序）、定理73（汇合性）	为长时运行智能体提供数学可证明的无副作用卸载与组合不变式。
元框架层 (Cordis)	可逆效应与反应式余效应	状态与逆操作打包；依赖关系图声明式自动解析	取消特权内核，从架构根源消除修改框架导致的上游代码分叉成本3。
运行时层 (DSH)	纯追加式会话日志3	基于事件流的轨迹视图，支持断点复原、重放与分支派生	将智能体运行全过程记录为不可变的事实源，确保可追踪性。
预设模式层	四种运行模式（标准、代码/PTC、极简、创造）3	涵盖全工具链 Coding、代码化工具编排、基准评估与动态插件创作9	同时接管端侧开发体验与智能体自演进试验场。

       Cordis元框架的关键工程突破，在于尝试解决传统开源框架中长期存在的“扩展即分叉（Fork）”痛点9。在 LangChain 等传统框架中，如果开发者需要替换底层的会话持久化逻辑或修改核心调度循环，往往必须直接修改源码，这会导致自定义代码与官方上游仓库逐步脱节，后续升级成本极高9。Cordis通过反应式余效应机制，使得任何核心组件的替换都可以通过配置层的服务重新注册来完成，无需动用框架主线代码9。同时，Cordis引入可逆效应，要求每一个插件在加载时必须声明对应的卸载与状态还原操作，从而在理论上赋予了智能体在长时运行过程中无缝热重载组件的能力。

OpenAI Codex Harness：以“沙盒隔离+三阶产品化接口”为核心的工业工程主义

       与DSH追求理论完备与高度解构的范式不同，OpenAI推出的 Agents SDK 与开源 Codex Harness（openai/codex）遵循严苛的工业工程主义1。OpenAI认识到，在企业级生产环境与真实软件开发场景中，模型本身的灵活性必须受到严格的安全边界与产品化工程接口约束1。因此，OpenAI 在物理架构上确立了控制平面（Harness）与计算平面（Sandbox）的分离模式，并通过 openai/codex 开源项目推出了面向不同接入深度的三阶集成战略3。
       在计算与控制分离设计中，Harness专职承载智能体逻辑调度、多智能体手势接力（Handoffs）、审批拦截以及内存决策，其本身并不直接执行具有物理副作用的代码1。所有真实的文件读写、代码编译及系统命令调用，均被下沉至计算平面的独立沙盒中（支持 macOS seatbelt、Linux landlock 及 Windows AppContainer 等 OS 级沙盒）3。通过声明式的 Manifest 编排机制，开发者能够以 Unix 风格的只读（ro）或读写（rw）权限精确控制数据挂载1。同时，集成 Temporal.io 持久化引擎与 SQLite 状态机，为系统提供了容错快照打点与 Rehydration 恢复能力1。
      在产品接入与开发者操纵层面，OpenAI 拒绝了“统一强制重写框架”的做法，而是将开源 Codex Harness 拆解为针对三种典型场景的精准操纵工具链8：

1. CLI 工具 codex exec（无干预自动化流水线）：专为一次性后台任务、持续集成（CI/CD）流水线或自动化脚本设计8。开发者只需传入指令或 Markdown 任务文件，codex exec 即可在预置权限沙盒内运行有边界的智能体工作流，并返回确定性的结构化 JSON/JSONL 结果8。简单、高效，彻底隔离外部副作用风险8。
2. 官方 Codex SDK（程序员的编程式终极操纵杆）：支持 TypeScript 与 Python 等主流语言，为应用程序提供了直接的 API 级控制能力7。开发者可以通过代码精准启动、暂停、恢复或流式传输（Streaming）Codex 任务，显式掌控 Thread（会话线程）与 Turn（执行轮次）的完整生命周期8。
3. Codex app-server 核心引擎（彻底融入产品的智能体心脏）：作为本次开源的核心亮点，app-server 是智能体嵌入复杂产品形态（如 IDE 插件、团队协作平台、独立 Desktop 应用）的关键8。它通过详细记录的客户端协议（标准 JSON-RPC 接口），允许宿主应用与本地 Codex 守护进程建立长连接8。宿主应用不仅能够跨轮次维持会话上下文、实时接收事件流，还能灵活挂载应用侧拥有的 MCP 服务，并在触发高危操作时无缝接入客户端自定义的人类审批（Approval）流程8。

两种范式的横向技术对比

       DeepSeek Harness 与 OpenAI Codex Harness / Agents SDK 的技术路线差异，构成了当前智能体基础设施演进的两个典型极点3。

比较维度	DeepSeek Harness (DSH)	OpenAI Codex Harness / Agents SDK
核心设计哲学	理论驱动，解构特权内核，一切皆插件	场景驱动，控制与计算分离，三阶集成工具链导向
底层开源许可	MIT（TypeScript 编写）	Apache-2.0（Rust 编写核心仓库 openai/codex）
接入层级架构	统一 Web UI / Headless Profile，完全依赖插件组装	codex exec (CLI) + Codex SDK + Codex app-server (JSON-RPC)
安全隔离模型	进程内插件化隔离（依赖 dispose 逆操作）	进程外 OS 级沙盒隔离（seatbelt / landlock / Manifest 权限）
状态持久化与重放	追加式事件日志（Append-only Event Log）	SQLite 会话存储 + Temporal.io 快照打点与 Rehydration 恢复
主攻目标场景	智能体 Runtime 基础设施与自进化试验场	CI/CD 自动化、应用代码掌控力与深度嵌入产品的 Agent 引擎

战略透视：五级开源战略模型下的体系化审视

五级开源战略分层模型定义

       为了准确判定各类开源项目的真实战略意图及其对产业生态的深远影响，本研究引入五级开源战略分层模型。该模型超越了“开源即无私”或“开源即营销”的简单二元论，以治理权归属、商业闭环路径以及国家数字主权属性作为核心评估基准。
L1级为市场战略，在此层级，开源主要被定位为获客漏斗、开发者心智占领工具以及品牌信任杠杆。发起方牢牢掌握项目治理权，源码虽然开放但社区贡献门槛极高。L2级为技术战略，开源被视为跨组织协同研发的方式，旨在通过社区力量降低重复造轮子的工程成本，项目通常保持积极接收 Pull Request（PR）的态度。L3级为商业战略，开源项目演变为行业共建的生态底座。发起方通常将治理权移交给中立基金会，消除竞品厂商的安全顾虑，进而通过上层商业化分层抽租。L4级为资本战略，开源社区活跃度被转化为资本市场的估值乘数，其终极目标是通过并购或上市实现资本退出。L5级为国家创新战略，开源上升为国家数字主权、自主可控以及新质生产力的战略载体，具备极高的合规门槛与政策托底属性。

全球主流 Agent 与基础设施开源项目矩阵定位

       基于五级战略模型及涵盖治理权、PR政策、商业模式、安全维护等维度的10题自检评估体系，对全球代表性开源项目进行体系化扫描，可以清晰勾勒出各项目的战略定性。

项目名称	主导厂商/组织	治理权与代码贡献政策	核心开源许可	自检得分倾向	最终战略层级
Claude Code	Anthropic	完全闭源，不开放源码	商业专有许可	全 A（闭源）	L0（完全闭源产品） [cite: ]
DeepSeek Harness	DeepSeek	单一公司独裁，关闭核心 PR	MIT 许可	9A / 1B	L1（市场战略极致形态） [cite: ]
OpenAI Codex	OpenAI	OpenAI 主导，Apache-2.0 开源 Rust 核心	Apache-2.0	5A / 5B	L2 → L3（技术协同向生态底层演进） [cite: 7, 8]
LangChain	LangChain Inc.	公司主导，积极吸收社区 PR	MIT 许可	6A / 4B	L1 → L2（技术协同过渡） [cite: ]
Redis	Redis Ltd.	公司主导，因变更许可引发社区分叉	BSD / SSPL	8A / 2B	L1（受制于商业收割） [cite: ]
JBoss	Red Hat (原JBoss)	公司独裁，已被高价收购	LGPL 许可	9A / 1B	L1（已完成 L4 资本退出） [cite: ]
Kubernetes	CNCF 基金会	多厂商共同治理，TSC 决策	Apache-2.0	1A / 9B	L3（商业战略中立样板） [cite: ]
Android (AOSP)	Google / OHA 联盟	开放源码，GMS 闭源抽租	Apache-2.0	1A / 9B	L3（生态分层抽租巅峰） [cite: ]
OpenHarmony	开放原子开源基金会	基金会共治，SIG 组协作	Apache-2.0	1A / 9B	L5（国家创新战略根社区） [cite: ]

DSH的战略错位：高维叙事与低维治权之悖论

       通过对DSH的深入剖析，可以观察到一种显著的“战略错位”现象。在市场传播与技术叙事中，DSH被赋予了“自进化 Agent 操作系统”、“Agent 时代的 Android”以及“递归自我改进（RSI）基石”等极高维度（L3至L5级）的产业愿景。然而，通过自检工具严格度量，DSH在治理权归属、PR接收政策、社区 LTS 维护以及安全审计等方面，均表现出绝对的单一公司控制特征，实际定位严格驻留在 L1 市场战略 层级。
这种高维叙事与低维治权之间的落差，揭示了DSH当前面临的深层困境。DeepSeek希望借助 MIT 许可和 Cordis 架构的开放性，吸引全球开发者为其构建庞大的插件生态，从而抢占智能体运行时的定义权3。但同时，DeepSeek又保留了对核心仓库的绝对掌控权，不仅在 rc 阶段关闭了主线代码的 PR 通道，也未表现出任何将项目移交给中立机构的意愿。与 Android（Google 联合 OHA 联盟共建）或 Eclipse（IBM 彻底捐赠给独立基金会）的成功经验对比，DSH 这种舍不得让渡治理权的保守心态，将成为其从“高热度 AI 工具”跨越为“全球通用基础设施（L3）”的实质性屏障。
对比之下，OpenAI 将其 Codex Harness 核心仓库以 Apache-2.0 协议开源，并提供 codex exec、SDK 和 app-server 等完善的标准接口，展现出了从 L2 向 L3 级平台化生态跃迁的明确战略路线7。

批判性反思：DeepSeek团队开源理念的认知局限与学术依赖

过度学术化思维与工业真实场景的严重脱节

        DeepSeek团队在设计DSH时展现了卓越的理论构建能力，通过严密的数学推导将“时空可组合性”转化为Cordis元框架的代码实现5。然而，这种过度的“学术第一性原理”偏好，导致项目在面对复杂真实的工业级产业挑战时，暴露出了明显的工程适用性短板。
        学术推导的核心假设漏洞在于物理世界跨进程副作用的不可逆性。Cordis在数学上证明了“定理61：恢复精确性”，即通过插件提供的 dispose 逆操作，可以完美复原系统的运行状态。这一数学定理在进程内的内存状态变更（例如取消事件监听、释放内存变量）中完全成立，但在真实的智能体应用中，智能体的大量核心行为必然涉及跨进程与物理世界的交互。
       当智能体通过 API 发起真实资金支付、发送不可撤回的电子邮件，或对生产环境数据库执行破坏性写操作时，代码层面的 dispose 逆操作在物理时域上根本无法撤销已发生的外部副作用。DeepSeek过度执念于在框架内部通过纯数学机制解决一致性问题，而忽略了工业界普遍采纳的“强隔离沙盒 + 补偿事务机制（Saga Pattern） + 显式人工审批”这一更加实用的工程路径3。相比之下，OpenAI 通过 Codex app-server 的客户端 JSON-RPC 协议与沙盒 Manifest，将高风险操作严格约束在客户端审批流程中，体现了对物理工程副作用的敬畏8。

“不收PR”背后的治理断层与生态信任黑洞

       DSH在开源运作中推行“允许并鼓励外部编写插件，但长期关闭核心仓库代码 PR”的政策。DeepSeek团队将其解释为架构选择的必然结果，即 Cordis 已经将所有能力解构为插件，因此任何扩展均无需修改上游主线代码。
       这种看似优雅的技术解释，在产业工程视角下掩盖了深层次的治理缺陷：
       首先是补丁孤岛效应。在工业落地过程中，开发者不可避免地会遇到 Cordis 核心逻辑在特定私有云环境、特殊操作系统或边缘硬件下的适配缺陷9。拒绝接收 PR 意味着社区修复这些底层 Bug 的努力无法汇入官方主线，开发者只能被迫维持各自私有的分叉版本，这急剧增加了整个生态的长期维护成本9。
       其次是生态供应链的安全黑洞。DSH 宣扬“一切皆插件”，但其插件运行机制完全缺乏现代工业级操作系统的安全防护3。DSH 插件与 Harness 核心运行在同一个 Node.js 进程中，共享完全相同的系统权限。在缺少官方签名认证、安全准入审核以及进程级沙箱隔离的情况下，第三方恶意插件可以轻易窃取环境变量中的敏感凭证或注入恶意代码。将供应链安全责任完全甩给终侧开发者，反映出团队在构建大型产业生态时对安全治理考量的缺失。

预支远期期权与当前工程落地的非对称性

       部分资本与行业分析将DSH奉为“自进化智能体与 Harness 级递归自我改进（RSI）的破局点”。这类高维叙事在逻辑推演上固然令人振奋，但在现阶段工程实现上存在严重的非对称性。
智能体要实现真正的自进化，必须形成闭环的“感知-行动-评估-学习”反馈回路2。DSH 当前仅完成了底层“运行时热重载”这一单一工程动作，即允许智能体在内存中动态替换自身配置或插件9。然而，实现自进化所必需的另外三个核心支撑模块在当前 DSH 版本中均处于缺失状态：
       一是缺乏可靠的自动化评估闭环，智能体无法客观判断“自我修改后的 Harness 是否比修改前更优秀”，极易陷入死循环崩塌4；二是缺乏因果归因能力，大模型目前无法准确诊断任务失败究竟源于模型本身推理缺陷、Prompt 表达不当还是 Harness 插件代码 Bug；三是缺乏跨进程事务的安全回滚机制，一旦自演进尝试造成破坏性外部影响，系统无法实现安全自愈。将远期的理论可能性包装为当前的架构实效，这种做法容易引发产业界对智能体基础设施落地难度的盲目乐观。

远景破局：中国开源大模型团队走向全球竞技舞台的战略路线图

从“学术出海”转向“工业共建”：跨越治权与生态壁垒

       中国开源大模型团队在过去几年凭籍极高性价比的模型与出色的推理性能，在全球开发者中建立了广泛的影响力。然而，在从“单体模型开源”迈向“智能体基础设施构建”的新阶段，中国团队必须完成从“学术论文驱动代码开源”向“现代工业级开源治理”的范式跨越。
       全球开发者对开源基础设施的信任，不仅来源于代码的开放，更来源于治理的中立。如果中国团队希望打造全球通用的智能体运行时标准，就必须拿出让渡治理权的勇气。在项目度过早期孵化期后，应主动推动将核心代码捐赠给 Linux 基金会、CNCF 或开放原子开源基金会等独立机构，建立由多国工程师参与的技术监督委员会（TSC），彻底消除海外企业对单一商业公司掌控项目的安全顾虑。
       同时，团队需要彻底改变“封闭开发、拒绝 PR”的态度，建立透明的 RFC（Request for Comments）演进机制，积极接纳全球顶尖工程师的补丁与架构建议，将社区智力真正转化为项目演进的动力。

构建三位一体的全球开源Agent生态攻守策略

       面对 OpenAI（以 codex exec / SDK / Codex app-server 构建的三阶架构）与 Anthropic 等巨头在智能体基础设施领域的生态围剿，中国开源团队在架构设计上应当摒弃单一的理论偏执，采取“汲取所长、三位一体”的融合演进路线3。
下一代高竞争力的开源智能体基础设施，应当在架构层面融合三个维度的核心能力：

• 理论解构与高扩展性（汲取 DSH 优势）：保留解构特权内核的设计思想，将模型适配、工具注册与调度逻辑解耦为标准化插件，确保框架具备极强的场景自适应能力5。
• 产品化分层接口（汲取 OpenAI Codex 优势）：提供类似 codex exec 的无干预 CLI、强类型的客户端 SDK 以及基于标准 JSON-RPC 协议的 app-server 引擎，满足从 CI 流水线到复杂产品集成的多元消费诉求8。
• 工业级安全与沙盒隔离（汲取 OpenAI 沙盒优势）：引入控制平面与计算平面的物理分离，强制要求所有物理副作用操作运行在 OS 级强隔离容器沙盒中，并建立插件机制的签名认证与权限控制3。

国家L5战略视角下的民企开源定位与协同机制

       中国将开源明确上升为国家战略，强调“促进开源生态繁荣”与建设国家级 AI 开源社区。在此宏观背景下，中国开源生态需要理清商业开源项目（L1/L3）与国家创新战略（L5）之间的分工与协同关系。
       必须认识到，以 DeepSeek 为代表的商业创新企业，其核心优势在于快速敏捷迭代、捕捉全球开发者心智以及在技术前沿领域进行高风险探索（L1/L3）。国家级 L5 战略（如数字主权、信创根社区）不应强行绑定于商业公司的早期探索项目之上，否则容易导致创新项目因承载过重的合规与行政负担而失去国际竞争力。
       更为科学的模式是构建“前店后厂”的双轨协同机制：允许商业公司与研发机构作为“前店”，采用高度市场化、国际通用 permissive 许可（如 MIT/Apache-2.0）快速走向国际市场，在全球竞技场抢占开发者心智与技术话语权；而国家级开源基金会与研究机构作为“后厂”，对经过市场检验的优秀开源项目进行工程加固、安全审计与标准化沉淀，将其二次转化为支撑国家数字主权的安全底座（L5）。这种双轨机制既能保持前端创新的极致灵活性，又能确保后端数字基础设施的自主可控。

结论与行动建议

       DeepSeek Harness 的开源，代表了中国技术团队在智能体基础设施领域一次极具深度的理论与架构探索5。它通过 Cordis 框架把“一切皆插件”的技术范式推向了新的高度5。然而，OpenAI Agents SDK 及最新开源的 Codex Harness（openai/codex）演进路径明确地表明，工业界生产环境与真实产品落地，需要的是一套拥有强隔离沙盒、持久化容错机制以及 codex exec（自动化 CLI）、Codex SDK（代码控制）与 Codex app-server（产品引擎）三阶清晰接入界面的工程确定性方案3。
       DeepSeek 团队并非缺乏开源技巧，而是精明地将 L1 市场战略推演到了极致。但其过度的学术化思维、对物理世界不可逆副作用的忽视，以及拒绝让渡治理权的封闭心态，构成了其迈向全球统治级生态（L3）的实质性壁垒。
       综合上述分析，针对不同生态参与方提出如下落地行动建议：
       对于企业级技术选型与产品落地团队，在面对长时运行、涉及资金交易或强合规要求的核心业务场景时，应当保持工程理性，优先选择控制平面与计算平面分离、具备沙盒隔离的确定性方案3；而在需要将 Agent 彻底融入自有产品生态时，可参考 Codex app-server 的 JSON-RPC 守护进程设计模式，实现会话持久化与端侧人类审批8。
       对于科研机构与学术探索团队，DSH 凭借其纯追加日志、全解耦的 Agent Loop 以及 Cordis 热重载能力，依然是进行智能体范式研究、多模型 Harness 效应对比以及自进化机制探索的最佳试验平台9。
        对于致力于走向全球舞台的中国开源大模型团队，应当坚定不移地走“技术高维创新 + 接入产品化 + 治理开放中立”的联合路线8。在架构上兼顾理论前沿与工业级确定性，在接入上提供完善的 SDK 与 App Server 协议，在治理上打破封闭的垄断心态，主动拥抱全球中立基金会与开发者社区，方能在全球智能体时代的竞技舞台上建立起真正不可替代的生态壁垒。

参考文献:

1. New OpenAI Agents SDK: The Dawn of Extreme Harness Engineering, New OpenAI Agents SDK: The Dawn of Extreme Harness Engineering – Superagentic AI Blog

2. Building Agents in 2026: Why the Harness Matters More Than the Model | by Micheal Lanham | Medium, https://medium.com/@Micheal-Lanham/building-agents-in-2026-why-the-harness-matters-more-than-the-model-eb72448fee04

3. DSH开源战略全景分析报告.md

4. awesome-deepseek-harness - AI Agents on GitHub | SkillsLLM, awesome-deepseek-harness - AI Agents on GitHub | SkillsLLM

5. DeepSeek Harness Tutorial: Architecture and Quick Start - Cloudsway, Cloudsway - Cloudsway

6. OpenAI's Agents SDK separates the harness from the compute - The New Stack, https://thenewstack.io/openai-agents-sdk-sandboxes/

7. Codex — The OpenAI Agentic Harness in TeamDay, Codex — The OpenAI Agentic Harness in TeamDay

8. Codex as a platform: build on the open agent harness | OpenAI Developers, https://developers.openai.com/blog/codex-as-a-platform

9. deepseek-harness: Swap Any Agent Component Without Forking | X-CMD, deepseek-harness: Swap Any Agent Component Without Forking | X-CMD | deepseek-harness

10. DeepSeek Harness developer preview: Everything is a plugin, DeepSeek Harness developer preview: Everything is a plugin

11. Agents SDK | OpenAI API, https://developers.openai.com/api/docs/guides/agents

12. Codex GitHub Action - ChatGPT Learn, https://learn.chatgpt.com/docs/github-action

13. moonbit-community/codex-sdk - GitHub, GitHub - moonbit-community/codex-sdk · GitHub

14. Always-running MetaHarness coding service on GCP - GitHub Gist, https://gist.github.com/ruvnet/e1008e2a4aa13bf2a991e6aca4028d03

15. codex-app-server · GitHub Topics, codex-app-server · GitHub Topics · GitHub