CodexBar 刷新循环Refresh Loop深度解析自适应刷新策略、后台更新与错误处理【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar本文围绕 CodexBar 的刷新循环机制展开从RefreshFrequency节奏配置、AdaptiveRefreshPolicy纯函数决策表到 agent-aware 本地编码活动感知扫描与后台错误处理完整讲解 CodexBar 如何在不登录的前提下保持用量数据的时效性。读完本文你将理解自适应刷新决策的完整输入输出链路、配置解析与迁移规则并能读懂相关日志与源码。刷新节奏Cadence七档频率与 UserDefaults 持久化支持的频率选项CodexBar 的刷新频率通过RefreshFrequency枚举定义位于 SettingsStore.swift共七档枚举值固定间隔秒说明manualnil完全手动不启动后台定时器oneMinute60每分钟刷新twoMinutes120每两分钟刷新fiveMinutes300每五分钟刷新旧版默认回退值fifteenMinutes900每十五分钟刷新thirtyMinutes1800每三十分钟刷新adaptivenil自适应全新安装默认值每个 tick 由策略动态计算间隔adaptiveAgentAwarenil自适应 需用户同意本地编码活动扫描的 agent-aware 模式关键设计点manual与两种 adaptive 模式的seconds均为nil但含义完全不同——manual代表根本没有定时器而 adaptive 模式有定时器、只是间隔不固定。这个区别直接影响下游启发式逻辑的取值详见后文。UserDefaults 存储与解析规则频率值通过SettingsStore持久化在UserDefaults的refreshFrequency键中。解析逻辑位于 SettingsStore.swift 的loadRefreshFrequency若存储值能解析为合法的RefreshFrequency直接原样保留包括manual和每个固定间隔绝不篡改用户选择若值为非法的不可识别字符串视为已有状态回退到旧版 5 分钟间隔fiveMinutes若值完全缺失nil且系统通过hadPreviousAppLaunch判定不存在任何先于迁移的启动标记检查providerDetectionCompleted键或迁移版本键见 SettingsStore.swift才解析为.adaptive并立即把解析结果持久化回 UserDefaults已有的旧版安装若缺少存储值同样落到 5 分钟回退保证升级后行为平滑。换句话说自适应模式只对干净的全新安装成为默认值任何检测到历史状态的安装都保持旧版 5 分钟行为直到用户主动更改。刷新行为Behavior后台任务、手动刷新与状态呈现后台刷新路径后台刷新运行在主线程之外统一调用UsageStore.refresh(enrichmentMode: .automatic)更新内容包括各 provider 的用量usage配额/积分credits可选的网页抓取web scrape如 OpenAI Web 数据。定时器通过Task.detached(priority: .utility)启动UsageStore.swift以 utility 优先级在后台轮询保证菜单 UI 的流畅响应。定时任务在设置变更或 store 释放时被取消deinit中也会主动 cancel。手动刷新Refresh now立即刷新在菜单中始终可用不依赖任何频率设置。手动刷新走enrichmentMode: .forcedForeground或.forcedBackground路径与自动刷新相互独立。陈旧/错误状态呈现当数据陈旧或刷新出错时菜单栏图标变暗并在菜单内呈现状态提示对应状态模型详见 docs/status.md。Provider 存储用量扫描可选仅当用户在设置中开启显示 Provider 存储用量Show provider storage usage时才会触发 provider 存储扫描。其调度策略为在后台按计划执行自动刷新期间做合并与节流coalesced/throttled手动刷新会强制触发但不会阻塞用量刷新的主路径。在 UsageStore.swift 中每次刷新都会调用scheduleStorageFootprintRefresh调度存储足迹刷新其产物保存在providerStorageFootprints字典中。自适应模式Adaptive Mode纯函数决策 定时器装配架构分层纯策略核心与平台适配层自适应刷新被刻意拆成两层纯策略核心AdaptiveRefreshPolicyCoreAdaptiveRefreshPolicyCore.swift阈值、延迟与决策表只存在于这一层。它不读时钟、不读ProcessInfo输入全部通过Input结构体传入同一个输入必然得到同一个Decision。App 适配层AdaptiveRefreshPolicyAdaptiveRefreshPolicy.swift负责把平台信号ProcessInfo.ThermalState归一化为ThermalPressure.nominal / .constrained再调用核心层。UsageStore.startTimer()在每个 tick 之前采集非纯净信号当前时间、上次打开菜单时间、低电量模式、热状态并喂给策略。策略输入AdaptiveRefreshPolicy.Input包含五个字段字段类型说明nowDate当前时间lastMenuOpenAtDate?上次打开菜单时间仅内存重启即清空lastCodingActivityAtDate?最近一次本地编码活动时间仅内存需用户同意才采集lowPowerModeEnabledBool系统低电量模式thermalStateProcessInfo.ThermalState系统热状态决策表first match wins策略表先匹配先生效在核心层以常量阈值实现AdaptiveRefreshPolicyCore.swift条件延迟Reason低电量模式开启或热状态为.serious/.critical30 分钟constrained菜单在最多 5 分钟前打开含未来/时钟调整时间戳年龄为负视为最近2 分钟recentInteraction菜单打开超过 5 分钟且不超过 1 小时5 分钟warm本地 Codex/Claude 会话活动发生在 5 分钟以内且菜单规则本应更慢5 分钟codingActivity菜单打开 1–4 小时前15 分钟idle无菜单打开记录或打开在 4 小时以上30 分钟longIdle每个决策天然落在 2–30 分钟区间内。注意codingActivity规则是有条件的只有当基础决策延迟大于 5 分钟上限codingActivityDelayCap时才会覆盖为 5 分钟源码nextDelay(for:)第 76-81 行的 guard 逻辑因此编码活动只能拉快而不能拖慢刷新。决策表刻意排除了配额quota、延迟latency、错误error、账号account和时间段time-of-day信号——这些信号不属于刷新时机的职责范围。内存态信号菜单打开与编码活动UsageStore仅在内存中跟踪两个信号UsageStoreAdaptiveRefresh.swiftlastMenuOpenAt每次打开菜单都会刷新可让两种自适应模式都提前触发下一次刷新lastCodingActivityAt只影响 Adaptive (agent-aware)且只能提前定时器shouldAdvanceAdaptiveTimer要求候选时间早于已排定时间才生效绝不会推迟既有 tick也不会引发同步刷新。两个信号都不持久化重启即丢失。Adaptive (agent-aware)本地编码活动扫描agent-aware 模式在普通自适应之上叠加本地编码活动感知涉及一个独立的隐私同意模型同意状态机持久化的adaptiveActivityScanConsent取值为undecided未决、allowed允许、declined拒绝定义于 SettingsStore.swift缺失或非法值会被修复为undecided而undecided绝不会授权扫描SettingsStoreDefaults.swift 中adaptiveActivityScanningEnabled要求consent .allowed选择declined会退化为普通 Adaptive当用户从 declined 状态再次显式选择 agent-aware 模式时consent 会被重置为undecided并重新询问SettingsStoreDefaults.swift。扫描流程与资源预算当 consent 为allowed时CodexBar 每 30 秒复用LocalAgentSessionScanner执行一次扫描运行ps -axo ... command检查进程列表识别 Codex/Claude 进程仅在检测到 agent 进程时按需运行lsof并枚举已知的会话元数据读取最近的 Codex rollout 记录解析其首行元数据与 mtime检查 Claude transcript 元数据。扫描设有严格的资源预算防止每 30 秒的扫描造成性能与隐私负担最多考虑 64 个 agent 进程最多解析 128 条 Codex rollout 元数据记录每个项目最多保留 64 个 Claude transcript 候选共享一个 512 条目、深度 1、150ms 的 agent-aware 目录元数据预算未来时间戳future-dated的 transcript mtime 被钳制为单个 scanner 生命周期内的时间戳钳制不保留文件路径从而保证未变化的未来日期文件无法每 30 秒制造出更新的活动信号。当 Agent Sessions UI 关闭时CodexBar 会丢弃扫描得到的 session 记录只保留最新Date。当低电量模式或严重/临界热压力出现时agent-aware 扫描暂停。隐私边界活动时间戳不持久化、不记录日志、不上传撤销同意时立即清除显式开启 Agent Sessions 会独立授权其本地扫描与 Adaptive 的同意选择互不影响Tailscale 发现与 SSH 功能始终保持在 Agent Sessions 设置之后不受自适应同意影响。定时器循环延迟重算、合并且行与日志两种自适应模式共用同一个 tick 循环UsageStoreAdaptiveRefresh.swiftnextAdaptiveTimerSleepDuration在每个 tick 前采集实时信号调用adaptiveRefreshDecision计算本次延迟把延迟经effectiveAutomaticRefreshInterval叠加BackgroundWorkPowerPolicy的低电量策略转换后存入adaptiveRefreshScheduledAtTask.sleep睡眠后调用与固定间隔模式完全相同的UsageStore.refresh(enrichmentMode: .automatic)。由于统一走refresh()isRefreshing合并守卫UsageStore.swift依然生效无论何种节奏模式同一时刻只会运行一个 provider 批量刷新避免并发重复请求。每次决策都会记录延迟与 reason 到adaptive-refresh日志分类格式如reasonwarm delay300sUsageStoreAdaptiveRefresh.swift。日志中从不出现provider 身份、账号、邮箱、工作区、路径、凭据或响应数据。启发式间隔解析normalRefreshIntervalForHeuristics()若干基于间隔的启发式逻辑reset-boundary 刷新、OpenAI Web 陈旧度、persistent-CLI-session 空闲窗口需要知道正常刷新多久一次。它们读取 normalRefreshIntervalForHeuristics()其解析规则为manual返回nil无定时器启发式随之失效固定间隔返回对应seconds两种 adaptive 模式调用策略实时计算当前决策的延迟因此这些启发式在自适应模式下依然活跃且大致成比例不会悄悄退化成手动模式行为。此外AdaptiveRefreshPolicy.nominalIntervalForHeuristics 300 秒即warmDelay作为代表节奏供无法访问实时信号的消费者如ProviderRegistry在UsageStore存在前构建 provider spec 时使用。测试验证策略表与定时器装配仓库用 Swift Testing 框架对决策表做了逐分支覆盖AdaptiveRefreshPolicyTests.swift.nominal/.fair热状态映射为不受限得到recentInteraction 2 分钟延迟.serious/.critical映射为受限得到constrained 30 分钟延迟低电量模式优先于热状态同样得到constrained菜单打开 301 秒5 分钟以上得到warm 5 分钟无历史记录得到longIdle 30 分钟编码活动为 0 秒时得到codingActivity 5 分钟。定时器装配层则由 AdaptiveRefreshTimerTests.swift 覆盖验证startTimer()如何把实时信号接入纯策略例如打开菜单前后决策从longIdle变为recentInteraction。策略核心层同样被离线回放工具AdaptiveReplayKit复用保证 app 与测试工具共享同一决策表。可选未来增强Optional future文档还记录了一个未执行的可选优化当没有任何日志存在时可通过codex exec --skip-git-repo-check --json ping自动播种auto-seed一条日志。该命令目前并未执行仅作为未来方向保留。小结CodexBar 的刷新循环以纯策略核心 平台适配装配分层设计AdaptiveRefreshPolicyCore维护一张可测试、可离线回放的决策表UsageStore.startTimer()负责在每个 tick 采集实时信号RefreshFrequency的 UserDefaults 解析保证了新旧安装的平滑迁移isRefreshing合并守卫与固定间隔模式共享确保任意节奏下都只有一个并发刷新agent-aware 模式则以严格隐私同意与资源预算为边界把本地编码活动引入刷新时机决策。相关状态呈现与 UI 细节可继续阅读 docs/status.md 与 docs/ui.md。【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CodexBar 刷新循环（Refresh Loop）深度解析：自适应刷新策略、后台更新与错误处理
CodexBar 刷新循环Refresh Loop深度解析自适应刷新策略、后台更新与错误处理【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar本文围绕 CodexBar 的刷新循环机制展开从RefreshFrequency节奏配置、AdaptiveRefreshPolicy纯函数决策表到 agent-aware 本地编码活动感知扫描与后台错误处理完整讲解 CodexBar 如何在不登录的前提下保持用量数据的时效性。读完本文你将理解自适应刷新决策的完整输入输出链路、配置解析与迁移规则并能读懂相关日志与源码。刷新节奏Cadence七档频率与 UserDefaults 持久化支持的频率选项CodexBar 的刷新频率通过RefreshFrequency枚举定义位于 SettingsStore.swift共七档枚举值固定间隔秒说明manualnil完全手动不启动后台定时器oneMinute60每分钟刷新twoMinutes120每两分钟刷新fiveMinutes300每五分钟刷新旧版默认回退值fifteenMinutes900每十五分钟刷新thirtyMinutes1800每三十分钟刷新adaptivenil自适应全新安装默认值每个 tick 由策略动态计算间隔adaptiveAgentAwarenil自适应 需用户同意本地编码活动扫描的 agent-aware 模式关键设计点manual与两种 adaptive 模式的seconds均为nil但含义完全不同——manual代表根本没有定时器而 adaptive 模式有定时器、只是间隔不固定。这个区别直接影响下游启发式逻辑的取值详见后文。UserDefaults 存储与解析规则频率值通过SettingsStore持久化在UserDefaults的refreshFrequency键中。解析逻辑位于 SettingsStore.swift 的loadRefreshFrequency若存储值能解析为合法的RefreshFrequency直接原样保留包括manual和每个固定间隔绝不篡改用户选择若值为非法的不可识别字符串视为已有状态回退到旧版 5 分钟间隔fiveMinutes若值完全缺失nil且系统通过hadPreviousAppLaunch判定不存在任何先于迁移的启动标记检查providerDetectionCompleted键或迁移版本键见 SettingsStore.swift才解析为.adaptive并立即把解析结果持久化回 UserDefaults已有的旧版安装若缺少存储值同样落到 5 分钟回退保证升级后行为平滑。换句话说自适应模式只对干净的全新安装成为默认值任何检测到历史状态的安装都保持旧版 5 分钟行为直到用户主动更改。刷新行为Behavior后台任务、手动刷新与状态呈现后台刷新路径后台刷新运行在主线程之外统一调用UsageStore.refresh(enrichmentMode: .automatic)更新内容包括各 provider 的用量usage配额/积分credits可选的网页抓取web scrape如 OpenAI Web 数据。定时器通过Task.detached(priority: .utility)启动UsageStore.swift以 utility 优先级在后台轮询保证菜单 UI 的流畅响应。定时任务在设置变更或 store 释放时被取消deinit中也会主动 cancel。手动刷新Refresh now立即刷新在菜单中始终可用不依赖任何频率设置。手动刷新走enrichmentMode: .forcedForeground或.forcedBackground路径与自动刷新相互独立。陈旧/错误状态呈现当数据陈旧或刷新出错时菜单栏图标变暗并在菜单内呈现状态提示对应状态模型详见 docs/status.md。Provider 存储用量扫描可选仅当用户在设置中开启显示 Provider 存储用量Show provider storage usage时才会触发 provider 存储扫描。其调度策略为在后台按计划执行自动刷新期间做合并与节流coalesced/throttled手动刷新会强制触发但不会阻塞用量刷新的主路径。在 UsageStore.swift 中每次刷新都会调用scheduleStorageFootprintRefresh调度存储足迹刷新其产物保存在providerStorageFootprints字典中。自适应模式Adaptive Mode纯函数决策 定时器装配架构分层纯策略核心与平台适配层自适应刷新被刻意拆成两层纯策略核心AdaptiveRefreshPolicyCoreAdaptiveRefreshPolicyCore.swift阈值、延迟与决策表只存在于这一层。它不读时钟、不读ProcessInfo输入全部通过Input结构体传入同一个输入必然得到同一个Decision。App 适配层AdaptiveRefreshPolicyAdaptiveRefreshPolicy.swift负责把平台信号ProcessInfo.ThermalState归一化为ThermalPressure.nominal / .constrained再调用核心层。UsageStore.startTimer()在每个 tick 之前采集非纯净信号当前时间、上次打开菜单时间、低电量模式、热状态并喂给策略。策略输入AdaptiveRefreshPolicy.Input包含五个字段字段类型说明nowDate当前时间lastMenuOpenAtDate?上次打开菜单时间仅内存重启即清空lastCodingActivityAtDate?最近一次本地编码活动时间仅内存需用户同意才采集lowPowerModeEnabledBool系统低电量模式thermalStateProcessInfo.ThermalState系统热状态决策表first match wins策略表先匹配先生效在核心层以常量阈值实现AdaptiveRefreshPolicyCore.swift条件延迟Reason低电量模式开启或热状态为.serious/.critical30 分钟constrained菜单在最多 5 分钟前打开含未来/时钟调整时间戳年龄为负视为最近2 分钟recentInteraction菜单打开超过 5 分钟且不超过 1 小时5 分钟warm本地 Codex/Claude 会话活动发生在 5 分钟以内且菜单规则本应更慢5 分钟codingActivity菜单打开 1–4 小时前15 分钟idle无菜单打开记录或打开在 4 小时以上30 分钟longIdle每个决策天然落在 2–30 分钟区间内。注意codingActivity规则是有条件的只有当基础决策延迟大于 5 分钟上限codingActivityDelayCap时才会覆盖为 5 分钟源码nextDelay(for:)第 76-81 行的 guard 逻辑因此编码活动只能拉快而不能拖慢刷新。决策表刻意排除了配额quota、延迟latency、错误error、账号account和时间段time-of-day信号——这些信号不属于刷新时机的职责范围。内存态信号菜单打开与编码活动UsageStore仅在内存中跟踪两个信号UsageStoreAdaptiveRefresh.swiftlastMenuOpenAt每次打开菜单都会刷新可让两种自适应模式都提前触发下一次刷新lastCodingActivityAt只影响 Adaptive (agent-aware)且只能提前定时器shouldAdvanceAdaptiveTimer要求候选时间早于已排定时间才生效绝不会推迟既有 tick也不会引发同步刷新。两个信号都不持久化重启即丢失。Adaptive (agent-aware)本地编码活动扫描agent-aware 模式在普通自适应之上叠加本地编码活动感知涉及一个独立的隐私同意模型同意状态机持久化的adaptiveActivityScanConsent取值为undecided未决、allowed允许、declined拒绝定义于 SettingsStore.swift缺失或非法值会被修复为undecided而undecided绝不会授权扫描SettingsStoreDefaults.swift 中adaptiveActivityScanningEnabled要求consent .allowed选择declined会退化为普通 Adaptive当用户从 declined 状态再次显式选择 agent-aware 模式时consent 会被重置为undecided并重新询问SettingsStoreDefaults.swift。扫描流程与资源预算当 consent 为allowed时CodexBar 每 30 秒复用LocalAgentSessionScanner执行一次扫描运行ps -axo ... command检查进程列表识别 Codex/Claude 进程仅在检测到 agent 进程时按需运行lsof并枚举已知的会话元数据读取最近的 Codex rollout 记录解析其首行元数据与 mtime检查 Claude transcript 元数据。扫描设有严格的资源预算防止每 30 秒的扫描造成性能与隐私负担最多考虑 64 个 agent 进程最多解析 128 条 Codex rollout 元数据记录每个项目最多保留 64 个 Claude transcript 候选共享一个 512 条目、深度 1、150ms 的 agent-aware 目录元数据预算未来时间戳future-dated的 transcript mtime 被钳制为单个 scanner 生命周期内的时间戳钳制不保留文件路径从而保证未变化的未来日期文件无法每 30 秒制造出更新的活动信号。当 Agent Sessions UI 关闭时CodexBar 会丢弃扫描得到的 session 记录只保留最新Date。当低电量模式或严重/临界热压力出现时agent-aware 扫描暂停。隐私边界活动时间戳不持久化、不记录日志、不上传撤销同意时立即清除显式开启 Agent Sessions 会独立授权其本地扫描与 Adaptive 的同意选择互不影响Tailscale 发现与 SSH 功能始终保持在 Agent Sessions 设置之后不受自适应同意影响。定时器循环延迟重算、合并且行与日志两种自适应模式共用同一个 tick 循环UsageStoreAdaptiveRefresh.swiftnextAdaptiveTimerSleepDuration在每个 tick 前采集实时信号调用adaptiveRefreshDecision计算本次延迟把延迟经effectiveAutomaticRefreshInterval叠加BackgroundWorkPowerPolicy的低电量策略转换后存入adaptiveRefreshScheduledAtTask.sleep睡眠后调用与固定间隔模式完全相同的UsageStore.refresh(enrichmentMode: .automatic)。由于统一走refresh()isRefreshing合并守卫UsageStore.swift依然生效无论何种节奏模式同一时刻只会运行一个 provider 批量刷新避免并发重复请求。每次决策都会记录延迟与 reason 到adaptive-refresh日志分类格式如reasonwarm delay300sUsageStoreAdaptiveRefresh.swift。日志中从不出现provider 身份、账号、邮箱、工作区、路径、凭据或响应数据。启发式间隔解析normalRefreshIntervalForHeuristics()若干基于间隔的启发式逻辑reset-boundary 刷新、OpenAI Web 陈旧度、persistent-CLI-session 空闲窗口需要知道正常刷新多久一次。它们读取 normalRefreshIntervalForHeuristics()其解析规则为manual返回nil无定时器启发式随之失效固定间隔返回对应seconds两种 adaptive 模式调用策略实时计算当前决策的延迟因此这些启发式在自适应模式下依然活跃且大致成比例不会悄悄退化成手动模式行为。此外AdaptiveRefreshPolicy.nominalIntervalForHeuristics 300 秒即warmDelay作为代表节奏供无法访问实时信号的消费者如ProviderRegistry在UsageStore存在前构建 provider spec 时使用。测试验证策略表与定时器装配仓库用 Swift Testing 框架对决策表做了逐分支覆盖AdaptiveRefreshPolicyTests.swift.nominal/.fair热状态映射为不受限得到recentInteraction 2 分钟延迟.serious/.critical映射为受限得到constrained 30 分钟延迟低电量模式优先于热状态同样得到constrained菜单打开 301 秒5 分钟以上得到warm 5 分钟无历史记录得到longIdle 30 分钟编码活动为 0 秒时得到codingActivity 5 分钟。定时器装配层则由 AdaptiveRefreshTimerTests.swift 覆盖验证startTimer()如何把实时信号接入纯策略例如打开菜单前后决策从longIdle变为recentInteraction。策略核心层同样被离线回放工具AdaptiveReplayKit复用保证 app 与测试工具共享同一决策表。可选未来增强Optional future文档还记录了一个未执行的可选优化当没有任何日志存在时可通过codex exec --skip-git-repo-check --json ping自动播种auto-seed一条日志。该命令目前并未执行仅作为未来方向保留。小结CodexBar 的刷新循环以纯策略核心 平台适配装配分层设计AdaptiveRefreshPolicyCore维护一张可测试、可离线回放的决策表UsageStore.startTimer()负责在每个 tick 采集实时信号RefreshFrequency的 UserDefaults 解析保证了新旧安装的平滑迁移isRefreshing合并守卫与固定间隔模式共享确保任意节奏下都只有一个并发刷新agent-aware 模式则以严格隐私同意与资源预算为边界把本地编码活动引入刷新时机决策。相关状态呈现与 UI 细节可继续阅读 docs/status.md 与 docs/ui.md。【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考