A search box above the Contents list filters TOC entries by each
linked section's full text content (not just the link title), so
e.g. searching "european" surfaces "Slash Commands" via its command
history date-format note. Pure vanilla JS/CSS, no dependencies --
the page is a static file opened directly in the default browser.
Tested interactively in Safari Technology Preview: filtering,
no-results state, reset, and click-through navigation all verified
working, in both the matched and empty-query cases.
Contacts was never actually broken by an Apple/OS bug -- it was a
wrong entitlement key in oAI.entitlements, now fixed (abf25bd). No
functional change here: the flag was already false in both places
this session, so behavior is identical; this just removes the
now-pointless beta-badge/conditional-row scaffolding built around it.
Confirmed root cause via tccd's own log output: the hardened-runtime
hardened-runtime prompting policy checks for
com.apple.security.personal-information.addressbook (the Contacts
framework's TCC service is still internally named kTCCServiceAddressBook,
a holdover from the old AddressBook framework), not
com.apple.security.personal-information.contacts as the entitlements
file had. With the correct key, tccd allows the prompt and access is
now granted correctly on both macOS 27 beta and 26.5.1 stable — this
was never an OS bug, notarization requirement, or beta-only issue.
Also keeps the fuller CNError domain/code/userInfo logging added while
diagnosing this, in case Contacts TCC issues resurface.
isContactsHiddenPendingAppleFix was flipped true on beta 2 after
CNContactStore.requestAccess returned instant "Access Denied" under
hardened runtime, while Calendar/Reminders/Location worked fine.
Rune just installed beta 4 and wants to retest.
Two machines that already had favorites before this sync feature
shipped will both have an empty favoriteModelsUpdatedAt, so the
first sync between them ties. Previously that meant the second
machine silently kept only its own set; now tied timestamps merge
via union and re-push, so no pre-existing favorites are lost.
Favorites now push/pull through a small oai_favorites.json file in the
same iCloud Drive folder used by Settings > Backup, reconciled by
last-write-wins timestamp on launch and app-become-active. Also adds
an Off/Daily/Weekly frequency picker so the full settings backup can
run itself (checked at launch and hourly) instead of requiring a
manual "Back Up Now" click every time.
Per Rune: the NSHelpManager-based Cmd+? fix from the last few commits
technically worked (registration was correct) but opened Apple's
broken generic Tips landing page instead of oAI's own content on the
macOS 27 beta this is built against — worse than the original
browser-tab behavior. Revisit at macOS 27 RC1 (see CLAUDE.md).
- openHelp() reverts to NSWorkspace.open() on index.html directly.
- Removed the "In-App Help" Ctrl+Cmd+H menu item entirely — HelpView's
panel (search already fully working) is reachable only via /help
from the input field now, by design.
- Renamed the custom CommandMenu("View") to CommandMenu("Chat") — it
was colliding with the "View" menu macOS auto-adds for
NavigationSplitView (Enter Full Screen, etc.), producing two
identically-titled top-level menus in the menu bar.
Cmd+/ was never reaching the "In-App Help" menu item — AppKit
auto-reserves Cmd+/ to open/focus the app's own Help menu (same
mechanism as Cmd+?), silently pre-empting any custom binding on that
combo, exactly like the earlier Cmd+H (Hide Application) conflict.
Verified live with computer-use before landing on Ctrl+Cmd+H:
Option+Cmd+/ has unpredictable menu-glyph rendering and didn't fire;
Option+Cmd+H is macOS's reserved "Hide Others" shortcut (visibly hid
other app windows when tested). Ctrl+Cmd+H showed no OS-level effect
and correctly opens the panel.
HelpView's search bar was already fully implemented and working —
this was purely a matter of the shortcut never reaching it.
GENERATE_INFOPLIST_FILE = YES with no INFOPLIST_FILE meant Xcode
synthesized Info.plist purely from INFOPLIST_KEY_* build settings and
silently ignored oAI/Info.plist on disk — so CFBundleHelpBookName/
CFBundleHelpBookFolder never made it into the built app. NSHelpManager
therefore couldn't resolve the book and macOS showed the generic Help
Center instead of oAI's help content (previous commit 74c8be8 fixed
openHelp() to call NSHelpManager, but that call had nothing to find).
Fix: point INFOPLIST_FILE at oAI/Info.plist so Xcode merges its extra
keys into the generated Info.plist, and add a synchronized-group
membership exception so Info.plist isn't also copied into Resources
(would otherwise produce a duplicate-file build warning).
openHelp() always found the bundled oAI.help folder, so it always took
the NSWorkspace.open(index.html) branch — handing the page to the
default web browser. The NSHelpManager branch, which launches the
native Help Viewer (with its built-in full-text search), was
unreachable dead code. Now always routes through NSHelpManager.
- ContentView now reads/writes SettingsService.sidebarVisible so the
NavigationSplitView sidebar's shown/hidden state survives relaunch,
matching the existing window size/position persistence.
- Default system prompt gains a rule: always reply in the user's
language, even for requests (e.g. translation) targeting another one.
rune
