【Bug已解决】Older Codex Desktop threads may not expose codex_app thread management tools 解决方案原始报错线索Older Codex Desktop threads may not expose codex_app thread management tools较老版本的桌面线程可能没有暴露出codex_app的线程管理工具导致在新版本里对这些旧线程无法做管理操作。一、现象长什么样系统升级后新增了「线程管理工具」。然后用户对新线程能用管理工具重命名、归档、合并但对升级前创建的旧线程这些工具根本不出现 / 调用报错「不支持」管理界面要么对旧线程显示残缺要么点管理就抛异常用户困惑同样的线程凭什么新的能用、旧的不能。 根因是能力是「按版本/创建时」固化的消费方却假设「所有实体都有最新能力」缺少协商与降级。二、背景能力为什么会随版本分化一个实体的能力通常在创建时就由当时的服务端版本决定旧版服务端创建线程时没有「线程管理」这一功能所以旧线程的元数据结构里没有对应字段新版服务端创建线程时才带上管理能力的元数据升级服务端不会自动「回填」旧实体通常出于安全/一致性考虑也不该偷偷改旧数据。 于是同一类实体因创建版本不同能力集不同——这是常态必须有机制应对。三、为什么旧线程不暴露工具根因3.1 消费方假设「能力总是最新」UI / 调度器遍历线程时默认每个线程都有thread_management能力直接调用 → 旧线程没有 → 报错。3.2 没有能力清单capabilities实体不携带「我支持哪些能力」的结构化声明消费方无从判断只能盲试。3.3 缺少协商 / 探测消费方不先问「你支持管理吗」就直接发管理指令。3.4 无降级路径旧线程不支持时没有提供「替代操作 / 提示用户升级线程」的降级直接失败。四、最小可运行复现假设所有线程都有能力下面演示「默认所有线程都有管理工具」如何对旧线程报错class Thread: def __init__(self, tid, capabilities): self.tid tid self.capabilities capabilities # 集合如 {chat} def manage_thread_bad(t: Thread): # 错误假设一定有 thread_manage 能力 if thread_manage not in t.capabilities: raise NotImplementedError(该线程不支持管理) return f管理 {t.tid} if __name__ __main__: old Thread(old-1, {chat}) # 旧线程无管理能力 new Thread(new-1, {chat, thread_manage}) print(manage_thread_bad(new)) try: manage_thread_bad(old) except NotImplementedError as e: print(旧线程报错:, e)旧线程因缺能力直接抛错——这就是「不暴露工具」在消费端的失败表现。五、解决方案一实体携带能力清单capabilities每个实体明确声明「我支持什么」消费方基于声明决策def get_caps(thread) - set: 返回线程支持的能力集缺失则视为空向后兼容旧实体。 return set(getattr(thread, capabilities, []) or []) def supports(thread, cap) - bool: return cap in get_caps(thread) if __name__ __main__: old Thread(old-1, [chat]) new Thread(new-1, [chat, thread_manage]) print(旧线程可管理?, supports(old, thread_manage)) # False print(新线程可管理?, supports(new, thread_manage)) # Truecapabilities从实体读取旧实体没有就当空集——消费方立刻知道「不能用」。六、解决方案二能力协商先问后做消费方在调用管理工具前先协商「目标是否支持」不支持就走降级def ensure_capability(thread, cap): 协商返回 (supported, reason)。 if supports(thread, cap): return True, ok # 旧线程提示可升级该线程以获得能力 return False, f线程 {thread.tid} 创建于旧版本不携带 {cap}请升级/迁移该线程 def manage_thread_safe(thread): ok, reason ensure_capability(thread, thread_manage) if not ok: return {action: degraded, reason: reason} return {action: managed, tid: thread.tid} if __name__ __main__: print(manage_thread_safe(Thread(old-1, [chat]))) # {action: degraded, reason: 线程 old-1 ... 请升级/迁移该线程} print(manage_thread_safe(Thread(new-1, [chat, thread_manage]))) # {action: managed, tid: new-1}先协商再动作旧线程得到清晰降级而非崩溃。七、解决方案三版本门控 一次性迁移对旧实体提供「迁移」路径把它们补齐到新版能力集只补元数据不偷偷改业务数据MIN_CAP_VERSION 2.0 def needs_migration(thread, created_version): 旧版本创建的线程需要迁移以补齐能力声明。 return created_version MIN_CAP_VERSION def migrate_thread(thread, created_version): 给旧线程补上能力声明不改动业务内容。 if needs_migration(thread, created_version): caps set(getattr(thread, capabilities, []) or []) caps.add(thread_manage) # 补齐新版能力 thread.capabilities list(caps) thread.migrated_from created_version return thread if __name__ __main__: old Thread(old-1, [chat]) migrate_thread(old, created_version1.0) print(迁移后能力:, old.capabilities) # [chat, thread_manage] print(可否管理:, supports(old, thread_manage)) # True迁移只补齐能力声明元数据让旧线程「获得」新工具的可见性而不动业务数据——这是最干净的修复。八、跨实体一致性feature flag新能力用 flag 控制旧实体 flag 默认关新建实体开协商而非假设任何「新能力调用」前先查capabilities可观测界面应标注「该线程为旧版部分功能不可用」迁移幂等迁移可重复执行且结果一致。九、排查清单「旧线程不暴露新工具」按下面排查实体是否带 capabilities 声明旧实体是否当空集处理第五节消费方是否先协商再调用还是假设都有能力第六节是否有迁移路径旧实体能否补齐能力声明第七节迁移是否幂等重复执行是否安全feature flag 是否一致旧实体 flag 状态对吗UI 是否标注旧版限制新建实体是否默认带新能力别把新实体也漏了日志是否记录实体创建版本与能力集。十、小结「旧版线程不暴露新工具」的根因是能力随创建版本固化而消费方假设所有实体都有最新能力缺少协商与降级。通用修复能力清单每个实体声明capabilities旧实体缺失即空集第五节先协商后做调用新能力前查声明不支持则走降级并提示迁移第六节一次性迁移只补齐旧实体的能力声明元数据不动业务数据flag 可观测新能力用 flag 控制UI 标注旧版限制第八节呼应第 106/107 篇。 一句话能力是「创建时固化」的消费方必须「按实体实际能力决策」而非「按最新版本假设」。用 capabilities 声明 协商 幂等迁移旧实体既能优雅降级又能被平滑补齐——这与第 131 篇 MCP 工具暴露、第 106 篇功能开关、第 87 篇幂等修复共同体现「版本演进中的实体必须有能力协商与向后兼容」。