尧图网站建设 
CodexBar 菜单栏 Widget 不显示在 Widget 图库时怎么排查注册与签名问题【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar在 macOS 上打开 Widget 图库桌面/通知中心里的 添加入口时如果完全看不到任何 CodexBar 的 Widget 条目先不要去改 SwiftUI 视图代码。docs/widgets.md 的 Visibility troubleshooting 章节直接给出了结论Widget 在图库中完全不出现时问题几乎总是出在注册、签名或系统守护进程缓存上而不是 SwiftUI 代码。本文按该文档的六步排查顺序走一遍。适用条件macOS 14WidgetExtension/Info.plist 中LSMinimumSystemVersion为 14.0WidgetExtension/project.yml 的 deploymentTarget 也是macOS: 14.0应用安装在默认路径/Applications/CodexBar.app如果你的安装位置不同下文命令里的APP变量需要换成实际路径。先确认扩展包的预期形态排查开始前先明确两个事实后面的检查步骤都依赖它们Widget 扩展是一个真正的 macOS app extension由 WidgetExtension/CodexBarWidgetExtension.xcodeproj 构建打包时带有 app-group 权限并放入主应用的Contents/PlugIns/目录docs/packaging.md 的 Bundle contents 一节。因此它应该位于/Applications/CodexBar.app/Contents/PlugIns/CodexBarWidget.appex。Widget 的 bundle ID 区分发布版和调试版release 为com.steipete.codexbar.widgetdebug 为com.steipete.codexbar.debug.widget。Scripts/package_app.sh 中由WIDGET_BUNDLE_ID${BUNDLE_ID}.widget派生而BUNDLE_ID在 debug 配置下会被改为com.steipete.codexbar.debug。排查时先确认你手上装的是哪一类构建后续WIDGET_ID要用对应的值。第一步确认扩展包存在于 macOS 期望的位置按 docs/widgets.md 给出的命令检查 appex 目录本身及其内部结构APP/Applications/CodexBar.app WAPPEX$APP/Contents/PlugIns/CodexBarWidget.appex WIDGET_IDcom.steipete.codexbar.widget # debug builds use com.steipete.codexbar.debug.widget ls -la $WAPPEX $WAPPEX/Contents $WAPPEX/Contents/MacOS判断方式ls应能列出 appex 目录、其Contents和Contents/MacOS子目录。如果WAPPEX不存在说明打包/安装环节没有把 Widget 扩展带进应用docs/packaging.md 明确该 appex 由 WidgetExtension 工程构建后与主应用一起分发此时应先解决安装完整性问题而不是继续后面的注册排查。第二步检查并修复 PlugInKit 注册pkdWidget 图库的可见性依赖 PlugInKit 对扩展的注册与选举election。先查看当前注册状态pluginkit -m -p com.apple.widgetkit-extension -v | grep -i codexbar || true pluginkit -m -p com.apple.widgetkit-extension -i $WIDGET_ID -vv文档对输出的说明表示该扩展被选举使用-表示被忽略。如果条目缺失或处于忽略状态执行强制添加并重新选举pluginkit -a $WAPPEX pluginkit -e use -p com.apple.widgetkit-extension -i $WIDGET_ID再用下面的命令检查是否存在重复注册例如旧版本安装残留导致的版本优先级冲突pluginkit -m -D -p com.apple.widgetkit-extension -i $WIDGET_ID -vv如果出现多个路径文档给出的处理是删除旧的安装并提升CFBundleVersion。注意这条操作会删除旧的 CodexBar 应用副本只删除确认是旧版本的安装不要动当前使用的/Applications/CodexBar.appCFBundleVersion需要在重新打包时修改WidgetExtension/project.yml 中该值来自$(CURRENT_PROJECT_VERSION)构建设置。第三步验证代码签名与 Gatekeeper 评估文档明确指出Widget 是由系统守护进程加载的任何签名失败都可能导致 Widget 被隐藏。对主应用、appex 和其中的可执行文件分别做严格校验并做 Gatekeeper 评估codesign --verify --deep --strict --verbose4 /Applications/CodexBar.app codesign --verify --strict --verbose4 $WAPPEX codesign --verify --strict --verbose4 $WAPPEX/Contents/MacOS/CodexBarWidget spctl --assess --type execute --verbose4 /Applications/CodexBar.app判断方式四条命令都应通过校验且不报签名错误。文档没有给出固定的成功输出文本以命令本身不报错为准。如果某一级签名失败需要回到打包环节修复签名见 docs/packaging.md默认走 ad-hoc 签名稳定证书打包需要显式设置CODEXBAR_SIGNINGidentity并提供APP_IDENTITY签名与公证由Scripts/sign-and-notarize.sh执行而不是手动修补 appex。第四步重启相关守护进程文档特别强调只重启 NotificationCenter 是不够的。下面命令会强制结束pkdPlugInKit 守护进程、chronod时钟守护进程需要管理员密码以及 Dock 和 NotificationCenter 进程系统会自动拉起它们副作用是桌面 Dock 和通知中心 UI 短暂重建killall -9 pkd || true sudo killall -9 chronod || true killall Dock NotificationCenter || true第五步打开 Widget 图库的同时观察系统日志在前一个终端窗口保持日志流然后在另一个窗口/操作里打开 Widget 图库观察 PlugInKit 与 WidgetKit 相关子系统的输出定位卡在哪一层log stream --style compact --predicate (process pkd OR process chronod OR subsystem CONTAINS PlugInKit OR subsystem CONTAINS WidgetKit)文档将这一步作为排查流程的收尾观察手段用于配合前四步操作定位注册或签名在系统层面的具体拒绝点。第六步核对打包一致性如果前面步骤都正常但 Widget 仍不出现文档列出三项打包层面的硬性要求任何一项不符都会导致系统不识别该 Widget 扩展检查项期望值Widget bundle IDrelease 为com.steipete.codexbar.widgetdebug 为com.steipete.codexbar.debug.widgetNSExtensionPointIdentifiercom.apple.widgetkit-extension见 WidgetExtension/Info.plist扩展文件夹名CodexBarWidget.appex如果这三项与实际不符说明拿到的应用包不是按 docs/packaging.md 描述的流程正确打包的需要重新构建并打包。可选操作重新播种 LaunchServices。文档标注这一步rarely helps, but low risk很少有效但风险低仅作为最后的补充手段/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -seed边界说明Widget 出现了但一直显示预览数据图库中完全没有条目和Widget 出现了但数据不对是两个不同的问题本文只处理前者。文档单独列出了后者的一个已知原因应用把快照写到了 fallback 路径而 Widget 读的是 app-group 容器此时应验证应用和 Widget 是否解析到同一个 app-group 容器详见 docs/widgets.md 的 Common post-visibility issue 一节。排查按上述顺序执行后如果 Widget 出现在图库中即代表完成文档对这一症状的全部归因就是注册、签名、守护进程缓存三类。如果六步走完图库仍然为空log stream捕获到的 pkd/chronod/WidgetKit 输出是继续定位的依据文档没有给出进一步的升级路径。【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CodexBar 菜单栏 Widget 不显示在 Widget 图库时怎么排查注册与签名问题
CodexBar 菜单栏 Widget 不显示在 Widget 图库时怎么排查注册与签名问题【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar在 macOS 上打开 Widget 图库桌面/通知中心里的 添加入口时如果完全看不到任何 CodexBar 的 Widget 条目先不要去改 SwiftUI 视图代码。docs/widgets.md 的 Visibility troubleshooting 章节直接给出了结论Widget 在图库中完全不出现时问题几乎总是出在注册、签名或系统守护进程缓存上而不是 SwiftUI 代码。本文按该文档的六步排查顺序走一遍。适用条件macOS 14WidgetExtension/Info.plist 中LSMinimumSystemVersion为 14.0WidgetExtension/project.yml 的 deploymentTarget 也是macOS: 14.0应用安装在默认路径/Applications/CodexBar.app如果你的安装位置不同下文命令里的APP变量需要换成实际路径。先确认扩展包的预期形态排查开始前先明确两个事实后面的检查步骤都依赖它们Widget 扩展是一个真正的 macOS app extension由 WidgetExtension/CodexBarWidgetExtension.xcodeproj 构建打包时带有 app-group 权限并放入主应用的Contents/PlugIns/目录docs/packaging.md 的 Bundle contents 一节。因此它应该位于/Applications/CodexBar.app/Contents/PlugIns/CodexBarWidget.appex。Widget 的 bundle ID 区分发布版和调试版release 为com.steipete.codexbar.widgetdebug 为com.steipete.codexbar.debug.widget。Scripts/package_app.sh 中由WIDGET_BUNDLE_ID${BUNDLE_ID}.widget派生而BUNDLE_ID在 debug 配置下会被改为com.steipete.codexbar.debug。排查时先确认你手上装的是哪一类构建后续WIDGET_ID要用对应的值。第一步确认扩展包存在于 macOS 期望的位置按 docs/widgets.md 给出的命令检查 appex 目录本身及其内部结构APP/Applications/CodexBar.app WAPPEX$APP/Contents/PlugIns/CodexBarWidget.appex WIDGET_IDcom.steipete.codexbar.widget # debug builds use com.steipete.codexbar.debug.widget ls -la $WAPPEX $WAPPEX/Contents $WAPPEX/Contents/MacOS判断方式ls应能列出 appex 目录、其Contents和Contents/MacOS子目录。如果WAPPEX不存在说明打包/安装环节没有把 Widget 扩展带进应用docs/packaging.md 明确该 appex 由 WidgetExtension 工程构建后与主应用一起分发此时应先解决安装完整性问题而不是继续后面的注册排查。第二步检查并修复 PlugInKit 注册pkdWidget 图库的可见性依赖 PlugInKit 对扩展的注册与选举election。先查看当前注册状态pluginkit -m -p com.apple.widgetkit-extension -v | grep -i codexbar || true pluginkit -m -p com.apple.widgetkit-extension -i $WIDGET_ID -vv文档对输出的说明表示该扩展被选举使用-表示被忽略。如果条目缺失或处于忽略状态执行强制添加并重新选举pluginkit -a $WAPPEX pluginkit -e use -p com.apple.widgetkit-extension -i $WIDGET_ID再用下面的命令检查是否存在重复注册例如旧版本安装残留导致的版本优先级冲突pluginkit -m -D -p com.apple.widgetkit-extension -i $WIDGET_ID -vv如果出现多个路径文档给出的处理是删除旧的安装并提升CFBundleVersion。注意这条操作会删除旧的 CodexBar 应用副本只删除确认是旧版本的安装不要动当前使用的/Applications/CodexBar.appCFBundleVersion需要在重新打包时修改WidgetExtension/project.yml 中该值来自$(CURRENT_PROJECT_VERSION)构建设置。第三步验证代码签名与 Gatekeeper 评估文档明确指出Widget 是由系统守护进程加载的任何签名失败都可能导致 Widget 被隐藏。对主应用、appex 和其中的可执行文件分别做严格校验并做 Gatekeeper 评估codesign --verify --deep --strict --verbose4 /Applications/CodexBar.app codesign --verify --strict --verbose4 $WAPPEX codesign --verify --strict --verbose4 $WAPPEX/Contents/MacOS/CodexBarWidget spctl --assess --type execute --verbose4 /Applications/CodexBar.app判断方式四条命令都应通过校验且不报签名错误。文档没有给出固定的成功输出文本以命令本身不报错为准。如果某一级签名失败需要回到打包环节修复签名见 docs/packaging.md默认走 ad-hoc 签名稳定证书打包需要显式设置CODEXBAR_SIGNINGidentity并提供APP_IDENTITY签名与公证由Scripts/sign-and-notarize.sh执行而不是手动修补 appex。第四步重启相关守护进程文档特别强调只重启 NotificationCenter 是不够的。下面命令会强制结束pkdPlugInKit 守护进程、chronod时钟守护进程需要管理员密码以及 Dock 和 NotificationCenter 进程系统会自动拉起它们副作用是桌面 Dock 和通知中心 UI 短暂重建killall -9 pkd || true sudo killall -9 chronod || true killall Dock NotificationCenter || true第五步打开 Widget 图库的同时观察系统日志在前一个终端窗口保持日志流然后在另一个窗口/操作里打开 Widget 图库观察 PlugInKit 与 WidgetKit 相关子系统的输出定位卡在哪一层log stream --style compact --predicate (process pkd OR process chronod OR subsystem CONTAINS PlugInKit OR subsystem CONTAINS WidgetKit)文档将这一步作为排查流程的收尾观察手段用于配合前四步操作定位注册或签名在系统层面的具体拒绝点。第六步核对打包一致性如果前面步骤都正常但 Widget 仍不出现文档列出三项打包层面的硬性要求任何一项不符都会导致系统不识别该 Widget 扩展检查项期望值Widget bundle IDrelease 为com.steipete.codexbar.widgetdebug 为com.steipete.codexbar.debug.widgetNSExtensionPointIdentifiercom.apple.widgetkit-extension见 WidgetExtension/Info.plist扩展文件夹名CodexBarWidget.appex如果这三项与实际不符说明拿到的应用包不是按 docs/packaging.md 描述的流程正确打包的需要重新构建并打包。可选操作重新播种 LaunchServices。文档标注这一步rarely helps, but low risk很少有效但风险低仅作为最后的补充手段/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -seed边界说明Widget 出现了但一直显示预览数据图库中完全没有条目和Widget 出现了但数据不对是两个不同的问题本文只处理前者。文档单独列出了后者的一个已知原因应用把快照写到了 fallback 路径而 Widget 读的是 app-group 容器此时应验证应用和 Widget 是否解析到同一个 app-group 容器详见 docs/widgets.md 的 Common post-visibility issue 一节。排查按上述顺序执行后如果 Widget 出现在图库中即代表完成文档对这一症状的全部归因就是注册、签名、守护进程缓存三类。如果六步走完图库仍然为空log stream捕获到的 pkd/chronod/WidgetKit 输出是继续定位的依据文档没有给出进一步的升级路径。【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考