[brennanb2025]

Stacked on #26116; retarget to main after it merges.

ELI5

Starting an SSH chat used the remote server's saved permissions, model, and reasoning effort instead of the desktop's choices. Someone who selected “Ask for approval” on the desktop could therefore get a new remote chat with Full access. New chats now carry the client's choices, and the composer shows the same choices that creation sends.

What Changed

• Resolve the desktop's saved chat defaults once, use them in the composer, and send them explicitly with chat creation. Picks made while creation is pending are folded into that request; replay after a lost response or reload keeps the original choices.
• The execution host honours explicit options without filling missing model choices from its own preferences. Clients that send no options retain the host's existing defaults.
• Negotiate support before sending the new optional create field. With an older server, the desktop continues to show that server's reported starting choices and omits the unsupported field. Released desktop and phone readers accept the additive support-response field; real released-code tests verify this, so the response field needs no client gate.
• Phone creation and workspace-plus-chat launch requests carry the phone's existing paired-host preferences. The agent launch path now preserves permission mode alongside model, effort, and Fast choices.
• Remember desktop model, effort, and Fast picks in the desktop's settings, including picks made in SSH chats. The existing host/provider confirmation still owns permission fallback before the first turn; provider-incompatible choices use the stricter supported mode.

Why

Defaults belong to the client starting the chat, while the execution host owns running it. Sending the same resolved choices that the composer uses follows the common pattern and avoids a second, independently resolved set of defaults on the remote server. Copying settings to every server would leave choices tied to server state and introduce synchronization work.

Differences from the common mechanism:

• Intended: keep Orca's existing global Chat preferences and empty-chat creation when a tab opens. Later composer picks use the existing option writes before Send, so the first turn still receives the chosen values without changing the tab lifecycle.
• Intended: older clients keep host-owned seeding, and newer clients use the old host's reported choices when it cannot accept explicit options. This preserves mixed-version compatibility and keeps the picker honest.
• Intended: the phone retains its existing paired-host preferences rather than gaining a device-local settings store. The choices it resolves are carried explicitly on the supported execution-runtime pairing path.
• Temporary: a phone paired to a desktop still cannot create a chat on that desktop's SSH workspace because execution-host forwarding is missing. Follow-up: phone chats on a desktop's SSH workspaces (U17).

Linked Issue

Internal SSH structured-chat audit, U31. Dependency: #26116.

Visual Proof

Pending coordinator-owned hidden-window Electron validation and screenshots. No rendered UI validation or live SSH run was performed in this lane; this PR remains a draft for that review and QA.

Testing

• I manually tested these changes locally
• Automated tests added/updated

On macOS: 224 targeted desktop, host, shared, and compatibility tests pass across 19 explicit files, and 100 mobile tests pass across four explicit files. Seven new regression assertions fail against the unchanged #26116 base. Six additional Fast-setting regressions fail before the encoded-option parsing fix and pass afterward.

Coverage includes conflicting desktop and SSH-host defaults, older hosts, old clients, an untouched model preference, composer picks before creation, exact replay after settings changes/reload, client-owned picker persistence, phone creation and workspace-plus-chat creation, lost phone launch replies, saved Fast on and off, and provider permission support. Unknown permission values fall back to Ask rather than silently becoming a host default.

Compatibility tests feed the new host response through released desktop result readers and phone response parsers for every pinned release in the existing cross-version suite, plus the newest release (currently v1.4.222). Each available released phone creator also proceeds to creation while omitting the new request options. These response readers are open; older host request schemas are strict, so the request field remains negotiated. The release fixture includes the phone sources and preserves each client's own imports.

Queued node, web, CLI, and mobile typechecks pass on the final implementation. Final pre-push checks: 21 of 22 static checks pass with those typechecks already completed. The sole local failure is the native code-quality audit, which reproduces five existing import-cycle warnings in mobile transport hooks and terminal document modules whose import graph matches origin/main.

Final-head CI is complete. Static analysis/typecheck, mobile checks, cross-version compatibility, relay integration, Linux/Windows packaging, nine desktop unit shards, and unit-selection evidence pass. Earlier failures in this lane's optional-argument and support-response assertions are corrected and now pass. The remaining failure is an existing timer-yield test in desktop shard 5: terminal-history-gc.test.ts observed five timer ticks where it requires more than five. Its test, implementation, and dependencies are unchanged from origin/main, and the prior-head shard passed. The aggregate verify check fails because of that shard; no new failure from this change remains. Conditional jobs were skipped and are not counted as passes. Real SSH/WSL and rendered picker behavior await coordinator QA.

Review

Draft: coordinator review and UI QA are pending.

Agent skill upstream boundary

• Not applicable: this change copies no upstream skill-installer implementation.

Notes

Author X handle: @BrennanKB5. Execution ownership and transcript authority stay on the host; this change carries starting preferences across the existing request paths.

Checklist

• This PR is focused on new-chat defaults
• I explained the problem, user-facing change, mechanism, and alternatives
• Before/after screenshots or videos attached
• Self-reviewed for correctness, security, and performance
• Cross-platform, SSH, folder-workspace, and mixed-version impact considered
• Full CI complete; every failure classified

[brennanb2025]

Closing. New-chat defaults (permission mode, model, effort) stay owned by each host, which is how main works today: the composer shows the host's starting choices and the create sends exactly those, and model or effort picks made in a host's chats are remembered on that host. This PR moved ownership to the client starting the chat, which contradicts that design, and most of its remaining machinery has since landed another way (each send and create now carry the model and effort). The one gap left, editing a remote host's chat permission default from the desktop, can follow the existing per-host Quick Commands settings if we want it.