AI administration · Sources checked November 7, 2026
If you manage Claude Desktop on third-party infrastructure, use the next few days to review the intended product surface and its retention policy together. A familiar-looking conversation window is a poor way to decide which data rule applies. This is a configuration-migration review for administrators, not a claim about every personal Claude account.
The November 10 checkpoint
Anthropic’s configuration changelog lists v4.16336.0 on November 3. After November 10, 2026 at noon PT (20:00 UTC), launches read an unset desktopHome as standard even with Chat retention configured. New Cowork conversations use coworkSessionRetentionDays, not chatSessionRetentionDays. The earlier v4.29.0 migration had a retention-mismatch exception; do not carry that assumption forward. Separately, November 5’s v4.23118.0 removes organizationPluginsUrl: its installed plugins stop loading. The replacement is allowedPluginMarketplaces.
Make the policy decision before the edit
The configuration reference defines standard as unified Chat and Cowork. off disables both; Code has a separate switch. The Cowork retention key dates to 1.52386.0. Unset means no deletion. In third-party mode, setting it can start deletion shortly after delivery; pinned tasks are not exempt. Spaces, memory and some other data remain. This is not a comprehensive erasure control.
Those facts create two different review questions: what work should people be able to do, and how long should its records remain? Give each question an owner. A UI preference should not silently settle a retention decision, and a retention cleanup should not silently broaden the available tools.
Build a small, useful migration record
- Record the actual fleet. List the installed Desktop version, deployment mode and configuration owner for each pilot group. Include the source that delivers the policy. Separate older devices rather than assuming that a profile has the same meaning everywhere. Do not put credentials or customer content in this inventory.
- Write the intended experience in plain language. Ask whether the group needs Chat, Cowork, Code or a combination. Compare that requirement with the documented choices before selecting a value. If the requirement cannot be represented by the supported options, escalate that mismatch instead of guessing a substitute.
- Get a retention decision, not just a number. Identify the record owner, intended lifetime and treatment of work already on devices. Review Chat and Cowork together, while recording any justified difference. A short value copied into production for testing can have consequences beyond the pilot conversation.
- Inventory required plugins. Name the business workflow that depends on each one and its owner. Treat a replacement marketplace as something to validate: check the intended plugin, its source and the access it needs. A plugin appearing in the interface is not enough evidence that the required workflow still works.
Test an outcome, then expand the rollout
Use a dedicated test account with fictional content and an approved staging policy. Start with one supported device version. Record what appears after launch, create a disposable conversation of the relevant kind, and verify which policy is actually effective. Keep expected and observed behavior in separate columns in your test record. Repeat for the other versions you intend to support.
For retention testing, use disposable data only and agree on the expected result before making changes. Include an inactive test conversation and any pinned-task scenario your team relies on. Do not infer that every copy of the underlying information is gone merely because a conversation disappears from the sidebar. Have the data owner define what evidence is sufficient for the organization’s own requirements.
For plugins, use a harmless representative workflow with a checkable output. If the expected plugin is missing or the output cannot be produced, stop that rollout group and record the failure. Avoid turning a failed migration test into an unreviewed expansion of permissions.
We have checked the vendor documentation, not installed these versions or reproduced their behavior. The practical deliverable is a short rollout record: version, policy source, intended surface, approved retention decision, required plugin outcome and named reviewer. That gives an administrator something concrete to approve before the next launch changes the experience.