[Bug] ZCode not registered as a macOS editor (no CFBundleDocumentTypes) — never appears in other apps' "Open in / Open With" lists (Finder, Codex, etc.)

提交前确认 · Pre-submission checklist

• I searched existing issues and confirmed this isn't a duplicate.
• I've read CONTRIBUTING.md.

ℹ️ The dropdown fields below (Category / Framework / Severity / Frequency / Version / OS) could not be set programmatically. Please select them manually when reviewing:

• Category: 文件 / 项目操作 · File / Project ops
• Agent framework: 不涉及框架 · Not framework-specific
• Severity: 影响体验 · Major (works but degraded)
• Reproducibility: 必现 · Always

---

问题描述 · Description

ZCode is not registered with macOS as an editor for source/text files, so it never appears in the "Open With" / "Open in" list of other applications (Finder, Codex Desktop, or any tool that relies on Launch Services to enumerate editors). Competing editors such as VS Code and Cursor appear correctly in that same list.

This blocks a key cross-tool workflow: e.g. while reviewing/evaluating code inside Codex, wanting to hand a file off directly to ZCode — there is no one-click path; the user must fall back to manual File → Open or drag-and-drop inside ZCode.

ZCode 没有在 macOS 上把自己注册为源码/文本文件的编辑器，因此它永远不会出现在其他应用（Finder、Codex Desktop、或任何依赖 Launch Services 枚举编辑器的工具）的 "打开方式 / Open in" 列表中。而 VS Code、Cursor 在同一列表里都显示正常。这阻断了跨工具协作流程。

---

复现步骤 · Steps to reproduce

1. Install ZCode Desktop on macOS.
2. Select a source file (e.g. main.py, app.exs) in Finder → right-click → Open With.
3. ZCode is missing from the editor list.
4. Inside Codex Desktop (or any AI tool), right-click a file → Open in.
5. ZCode is not offered, while VS Code / Cursor / Sublime are.

---

期望表现 · Expected behavior

ZCode should declare the document types it can open via CFBundleDocumentTypes in its Info.plist, registering itself as an Editor for common source/text UTIs (public.plain-text, public.source-code, public.data, plus a broad extension set: .py .js .ts .ex .exs .go .rs .md .json .yaml .toml .sh ...). It should also (ideally) install a zcode CLI shim in the user's PATH so tools that locate editors by command name can detect it.

---

实际表现 · Actual behavior

Evidence from Info.plist (verified on ZCode 3.3.4)

$ defaults read /Applications/ZCode.app/Contents/Info.plist CFBundleIdentifier
dev.zcode.app

$ /usr/libexec/PlistBuddy -c "Print :CFBundleDocumentTypes" /Applications/ZCode.app/Contents/Info.plist
# (nothing — key is absent)

CFBundleDocumentTypes is absent entirely; only a URL scheme is registered:

Capability	VS Code / Cursor	ZCode
CFBundleDocumentTypes (declares "I edit these files")	✅	❌
zcode CLI command in $PATH	✅ (code / cursor)	❌ (which zcode → not found)
Registered as Editor for source UTIs in Launch Services	✅	❌
URL scheme only	—	✅ (zcode://)

Launch Services dump confirms it

lsregister -dump shows ZCode only claims the zcode: URL scheme — no LSItemContentTypes / document-type claims, so macOS never offers it as an editor for files.

---

根本原因 · Likely root cause

ZCode ships without CFBundleDocumentTypes in Info.plist, so Launch Services does not treat it as an editor for any file type. Tools (Codex, Finder, etc.) that build their "Open in" lists from Launch Services editor registrations therefore never see ZCode.

Suggested fix (for the team)

1. Add CFBundleDocumentTypes to Info.plist claiming common source/text UTIs with CFBundleTypeRole = Editor.
2. Ship a zcode CLI helper in PATH (or document a zcode://workspace/open?path=... invocation that editor-detecting tools can call).
3. Consider adopting Apple's modern LSItemContentTypes (UTI-based) declarations over legacy extension lists.

A user-side duti workaround exists but is not a substitute for a correct app manifest:

brew install duti
duti -s dev.zcode.app public.plain-text all
duti -s dev.zcode.app public.source-code all

---

ZCode 版本 · ZCode version

3.3.4 (production, darwin-aarch64)

设备 / 系统 / 浏览器 · Device / OS

macOS 25.5.0 (Apple Silicon / arm64)

---

🙏 Thank you to the ZCode team. Proper editor registration would unlock the entire cross-tool workflow (and pairs with the related feature request to choose which existing conversation receives the opened file, rather than always starting a new one).

Start by inspecting /Applications/ZCode.app/Contents/Info.plist and the packaging configuration that produces it; verify the absent CFBundleDocumentTypes entry with PlistBuddy. Check the Launch Services registration after changes using lsregister -dump, and confirm ZCode appears in Finder's Open With list for the listed source and text files. The CLI shim is also mentioned as a possible related improvement, but its implementation location is not identified here.