[BUG] Conversations created via Quick Entry permanently ignore profile preferences and styles on BOTH macOS and Windows (v1.40609.0) — memory IS injected; not recoverable in main window or claude.ai web

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (searched all ~58 "quick entry" issues; closest related: #57672, #69273, #87928 — all distinct)
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Note: this bug is in the Claude Desktop app's Quick Entry feature on both macOS and Windows, not the Claude Code CLI. Filing here because area:desktop covers desktop app issues (precedent: #57672, #69273, #87928).

Any conversation created through Quick Entry (macOS: double-tap Option; Windows: quick entry shortcut/popup) is permanently excluded from account personalization:

• Profile preferences (Settings → Profile → "What preferences should Claude consider in responses?") are never applied.
• Styles are never applied.
• Memory (account-level memory from chat history) IS injected normally.

The defect is attached to the conversation itself, not to any client, account, or machine. Verified reproduction matrix, all on v1.40609.0 (f65e38, built 2026-08-27):

| Variable changed | Result |
|---|---|
| Continue the conversation in the main Desktop window (2nd turn+) | still broken |
| Continue the conversation on claude.ai web in a browser | still broken |
| Full local-state reset (rename entire Application Support/Claude, relaunch, re-login) | still broken |
| Second, unrelated account on the same machine | reproduces |
| Windows machine, same version, quick entry shortcut | reproduces |
| Control: "New chat" button in the main window, same account/machine/session | works correctly |

Conversations created via the normal "New chat" button apply preferences and styles correctly every time. There is no error, warning, or UI indication — the personalization layer is silently missing.

Why this looks server-side (diagnosis):

• Reproduces on Windows with the same version (1.40609.0) via the Windows quick entry shortcut — eliminating OS, hardware, and platform-specific code as causes. The common factor is the Quick Entry conversation-creation path shared by both platforms (and/or the server's handling of that creation request).
• Full local state reset does not fix it: quitting the app, renaming the entire ~/Library/Application Support/Claude directory (fresh install state, new install ID, fresh feature-flag fetch), relaunching and signing in again — Quick-Entry-created conversations still ignore preferences/styles, while "New chat"-button conversations on the same relaunched app apply them correctly. This rules out corrupted local cache/config and install-keyed flag cohorts. (Contrast with #57672, where clearing the cache partially changed Quick Entry behavior — here it changes nothing.)
• Reproduces with a second, unrelated account on the same machine — rules out account-scoped feature flags or account data corruption. Combined with the resets and cross-platform results above, every client-, account-, and machine-side variable has been eliminated.
• The claude.ai web client shares no Quick Entry code, yet shows the same symptom on the same conversation → the conversation record itself must be missing whatever marks it for personalization injection, and the backend honors that state on every subsequent turn.
• The asymmetry is consistent: memory is account-scoped and injected regardless of conversation attributes (works), while preferences/styles behave as conversation-scoped personalization (broken for these conversations only).
• Most likely cause: Quick Entry uses a different conversation-creation request (endpoint or payload) than the main window, and conversations born through it lack a field/flag required for the personalization layer.

This fits an existing pattern of Quick Entry using a separate, divergent code path:

• #57672 — Quick Entry sends messages to new chats but silently fails on existing chats (conversation routing differs from main window)
• #69273 — Quick Entry overlay fails with custom_3p_not_available in Bedrock mode while the main window works (request construction differs)
• #87928 — Voice dictation opens a "new chat" picker instead of inserting into the active chat

Impact:

• Users who rely on profile preferences (language, tone, formatting, workflow rules) or Styles get silently degraded responses in every Quick-Entry chat, with no indication why.
• The conversations are permanently broken — moving to the main window or web does not fix them, so the only remedy is abandoning the conversation and recreating it via "New chat".

What Should Happen?

A conversation started from Quick Entry should be identical to one started from the "New chat" button: profile preferences, styles, and memory all applied. At minimum, personalization should recover once the conversation is continued from the main window or web.

Error Messages/Logs

No error output — the failure is completely silent. No error, warning, or UI
indication in the app, and the reply streams normally (just without the
preferences/styles personalization layer).

Steps to Reproduce

1. Set a clearly verifiable profile preference in Settings → Profile (e.g., "Always answer in <language X>" or "Always start replies with the word TEST").
2. Optionally select a non-default Style.
3. In Claude Desktop main window, click New chat, send: "Summarize my user preferences." → Claude correctly reflects the preferences. (Control case — works.)
4. Open Quick Entry (macOS: double-tap the Option key; Windows: the quick entry shortcut/popup), type the same message, press Enter. → A new conversation is created; the reply shows no awareness of profile preferences, and the selected Style is not applied. Memory content from past chats IS clearly being used.
5. Open that same conversation in the main window and send a 2nd message asking about preferences. → Still not applied.
6. Open the same conversation on claude.ai in a browser and send another message. → Still not applied.

Reproduces 100% of the time for every Quick-Entry-originated conversation.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

Unknown — likely introduced in or shortly before 1.40609.0 (build was only days old at time of observation; no prior reports among the repo's ~58 Quick Entry issues)

Claude Code Version

Claude Desktop 1.40609.0 (f65e38), built 2026-08-27 — current latest release at time of filing, identical version on both machines

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Environment details:

• Machine 1: macOS Sonoma 14.x on iMac 27" (Late 2014, Intel) via OpenCore Legacy Patcher — unsupported hardware, disclosed upfront; irrelevant to the root cause given the Windows reproduction
• Machine 2: Windows PC, Claude Desktop 1.40609.0, quick entry shortcut — reproduces identically (OS dropdown above only allows one selection)
• Plan: Max
• Account has profile preferences set, a Style selected, and memory ("Generate memory from chats") enabled
• Cross-account: reproduces with a second, unrelated account. Cross-platform: reproduces on Windows with the same version. Cross-client: persists on claude.ai web. Survives full local-state reset.

Notes for triage:

• The affected build (1.40609.0, built 2026-08-27) was only days old when this was observed. If the Quick Entry conversation-creation path changed in this release, this may be a fresh regression — which would also explain the absence of prior reports for such a severe, silent failure.
• Easy A/B verification: compare the POST .../chat_conversations creation payloads and subsequent .../completion request/response behavior between a "New chat"-button conversation and a Quick-Entry conversation on the same account.
• Happy to provide a HAR capture or run a debug build if useful.