Conversation
The toast that warns the user about missing screen-recording access was gated on 'getSavedPreference() == true || appState.isRecording', but the recorder forces isRecording off the moment it detects the permission is missing, and getSavedPreference() is nil for users who have never explicitly toggled it. Net effect: the notice never surfaced for the exact case it was meant to alert on, and the user had no UI signal that recording was broken (the Resume button appeared to do nothing). Switch the guard to the 'didOnboard' UserDefaults flag so the notice appears whenever the user has completed onboarding and the permission is missing. Also re-evaluate the notice on every tab change to .timeline so a user who lands on the timeline after dismissing elsewhere still sees it (the session-dismiss flag prevents spam).
Cards in the timeline now carry a small 'Provider · Model' badge so the user can see at a glance which model produced them. Older cards saved before this change render without the badge (no placeholder), because the new fields are optional in the JSON metadata column — no DB migration required. Three places show the badge: - Canvas timeline card (CanvasActivityCard) — a small text line below the time range - Right-side detail card (MainView/ActivityCard) — a chip next to the category badge with a sparkles icon - Review-mode swipe card (TimelineReviewCard) — a chip next to the category pill A new 'TimelineActivity.providerBadge' computed property centralises the provider-id → human-label mapping (e.g. 'gemini' → 'Gemini', 'chatgpt_claude' → 'Claude' or 'ChatGPT' based on the model name), and looks up the model alias through ClaudeModel / CodexModel enums so 'sonnet' displays as 'Claude Sonnet' rather than the raw alias. Storage: TimelineCard, TimelineCardShell, TimelineActivity, and the TimelineMetadata JSON envelope gained optional 'providerId' and 'modelId' fields. LLMService stamps these onto every card it writes, using 'activeContext.id.providerLabel' for the provider and a new 'providerModelId(for:)' helper for the model.
The Claude CLI's --model flag accepts aliases (sonnet, opus, fable) or full names (claude-fable-5), but rejects the bare 'claude-sonnet' with 'It may not exist or you may not have access to it' → exit 1. Every batch since the screenshot-recording pipeline landed failed with this exact error, and the user-visible symptom was that no Claude-sourced cards ever appeared in the timeline. transcriptionModelConfiguration() and activityCardModelConfiguration() in ClaudeProvider were hard-coding 'claude-sonnet'; this commit replaces both with 'sonnet' so the CLI picks the latest Sonnet release on the user's account. Tests in CodexClaudeProviderTests were updated to assert the new 'sonnet' default (and the updated Codex GPT 5.6-luna default, which is handled in a separate commit).
The Settings → Providers tab now offers a model picker for the
Chat CLI providers (Claude and Codex), mirroring the existing
Gemini picker. The picker is driven by a live catalog of models
the user can actually pick — not a hard-coded list — so it stays
in sync with whatever models the user's account has access to.
Discovery: a new ChatCLIModelCatalog runs one tiny 'claude -p
--model <alias> OK' probe per known alias in parallel and pulls
the resolved full model name (e.g. 'claude-sonnet-5') out of the
JSONL response's 'modelUsage' key. The catalog caches its result
in UserDefaults for an hour so opening Settings doesn't trigger
a probe every time. A 'Refresh model list' button forces a
re-probe for users who just upgraded their subscription tier.
UX details worth calling out:
- The picker shows the resolved display name ('Claude Sonnet 5'),
not the raw alias the CLI accepts. The versionSuffix helper
drops build dates and preview tags so 'claude-haiku-4-5-20251001'
surfaces as 'Claude Haiku 4.5'.
- Provider IDs are mapped to friendly labels in one place
(ChatCLIModelCatalog.prettyName). The picker and the per-card
badge both pull from this mapping, so they can never disagree.
- Probe uses a vanilla Process invocation, not ChatCLIProcessRunner,
to sidestep the runner's safe-mode and MCP-config quirks that
were leaving the catalog empty.
Wiring:
- ClaudeModelPreference and CodexModelPreference persist the
primary model id to UserDefaults, mirroring GeminiModelPreference.
- ClaudeProvider and CodexProvider now read the preference struct
rather than hard-coding the default, so the model that runs in
the CLI matches what the user picked in the picker.
- LLMService.providerModelId(for: .claude/.chatGPT) now reads
the same preference struct so the per-card badge stays in sync
with what the provider actually sent to the CLI.
Claude Code 2.1.169+ added --safe-mode; 2.1.195+ added --effort; 2.1.191+ added --prompt-suggestions; --name is a subagent-only flag. Dayflow was passing all four unconditionally, so users on Claude Code 2.1.22 (January 2026, the version most users install first) saw every recording batch fail with 'error: unknown option --safe-mode' (or --name / --effort / --prompt-suggestions).
- Remove --safe-mode, --name, --prompt-suggestions from the cmdline
- Replace --effort with --settings JSON ('effortLevel' key) — universal across versions
- Add ClaudeCapabilityProbe that runs 'claude --version' once per process and gates --safe-mode on >= 2.1.169
- Defense in depth: --tools Read + --allowedTools still restrict the read scope, so older Claude Code versions stay sandboxed without the --safe-mode flag
Closes the Dayflow-wide batch-failure pattern on Claude Code < 2.1.169.
Author
|
Superseded by #346 (rebase onto v2.1.0). |
Author
|
Superseded by #347 (rebase onto v2.1.0). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Every recording batch fails with
error: unknown option --safe-mode(or--name/--effort/--prompt-suggestions) for users running Claude Code 2.1.22, the version most users install first.--safe-modelanded in 2.1.169 (June 8, 2026)--prompt-suggestionsin 2.1.191+ (June 24, 2026)--effortin 2.1.195+ (late June 2026)--nameis aclaude agentssubcommand flag, not aclaude -pflagDayflow's ChatCLIProcessRunner has been passing all four unconditionally since 2.0.3.
Fix
--safe-mode,--name,--prompt-suggestionsfrom the cmdline unconditionally--effort <level>with--settings '{"effortLevel":"<level>"}'— works on every Claude Code versionClaudeCapabilityProbethat runsclaude --versiononce per process and re-adds--safe-modeonly when the binary is ≥ 2.1.169--tools Read+--allowedTools Read(<path>)+--disable-slash-commandsstill restrict the read scope on older Claude Code versions without the--safe-modeflagThe probe is cached per process (3s timeout) and exposes
installedVersionDescriptionfor diagnostic UI.Test coverage
testOptimizedTranscriptionUsesRestrictedSafeModeAndExplicitLowEffort— now version-aware (prefix length depends on whether--safe-modeis included)testOptimizedCardsDisableToolsAndUseNormalAuthSafeMode— gates onClaudeCapabilityProbe.safeModeArgumentstestExistingClaudeCommandOnlyAddsRequestedReasoningEffort—--effort medium→--settings '{"effortLevel":"medium"}'testClaudeStreamingCommandIncludesExplicitEffort— same swap for the streaming pathtestClaudeOptimizedProfilesUseNormalAuthSafeMode— every profile agrees with the probe on whether--safe-modeshipsAll unit tests pass on Claude Code 2.1.22 (probe reports
falsefor safe mode, but command lines stay valid) and on 2.1.195+ (probe reportstrue).Tested on macOS with Claude Code 2.1.22 (the failing version) and 2.1.22 confirmed via
claude --version. Theunknown optionerror goes away, recording batches process, and 110+ cards render in the timeline.