top of page
Search

Claude Desktop, ChatGPT Desktop, and Raycast AI: Which One Can You Actually Manage?

Writer: MacSmithAI
MacSmithAI
5 days ago
6 min read

Three AI desktop clients are probably already on your fleet, and you deployed at most one of them. Once you have solved the inventory problem, a harder question arrives: which of these can you actually manage?


Not "which has a security page" — all three have one. The question is narrower and much less flattering: when you push a configuration profile to ten thousand Macs, which settings does the app honour, and which are a polite request you are making of your users? I read all three vendors' documentation this week the way you read an MDM payload reference, and the answers are far less even than the marketing suggests.


Claude Desktop: real managed preferences, wide-open defaults

Anthropic's enterprise configuration article is the most useful of the three: it is written for someone holding a profile editor. "Administrators on Team or Enterprise plans can control Claude Desktop through system policies," and for macOS: "Claude Desktop reads preferences from the domain com.anthropic.claudefordesktop."


The keys matter more than the mechanism. forceLoginOrgUUID will "Require login to belong to a specific organization," and the article is blunt about the failure mode: "Login fails if the authenticated account does not belong to a listed organization." For several orgs you pass a JSON array stored as a single string value — on macOS a <string> containing JSON text, not a real array.


Then the behavioural toggles, which are what make Claude Desktop different from the other two: isLocalDevMcpEnabled ("Enable local MCP servers"), isDesktopExtensionEnabled ("Enable/disable extensions"), isDesktopExtensionDirectoryEnabled, isClaudeCodeForDesktopEnabled, secureVmFeaturesEnabled ("Enable Cowork access in desktop") and allowedWorkspaceFolders — the "Filepath or filepaths the user can mount to Cowork." You can also pin versions with disableAutoUpdates.


Read the defaults column before you feel reassured. Every one of those booleans defaults to true, and allowedWorkspaceFolders defaults to "Unrestricted." Deploying the PKG and walking away does not give you a controlled client; it gives you an uncontrolled one with a documented way to control it.


Two gaps: a copy in ~/Applications lets "Users ... update without administrator privileges" and hides from any check that only walks /Applications, and neither Anthropic article mentions audit logging.


ChatGPT Desktop: the profile manages a browser, not the assistant

OpenAI does ship an MDM story for the macOS app, which I did not expect, and it is narrower than it looks. The article is titled "Manage ChatGPT desktop browser policies with MDM," and the operative word is browser: the app embeds Chromium, and the profile configures that. "It uses the same policy names and value formats as Chrome."


The domain is the strangest string in this post — com.openai.codex — and the page heads off the obvious bug report: "The ChatGPT desktop identifiers still contain Codex or codex. Use them exactly as shown." Save the plist as com.openai.codex.plist for Jamf's Application & Custom Settings payload, or set that preference domain name in an Intune macOS Templates → Preference file profile. Two sentences belong in your runbook verbatim: "A profile targeting Chrome's domain does not target ChatGPT desktop," and "Use managed preferences: a normal user preference written with defaults write does not make a policy mandatory."


The keys are Chrome's: PasswordManagerEnabled, CookiesBlockedForUrls, ExtensionInstallBlocklist, ExtensionInstallAllowlist, ExtensionInstallForcelist, ExtensionSettings, ExtensionAllowedTypes and ExtensionInstallSources. Genuinely useful — but no documented key for which workspace a user may sign into, none for the model, none for connectors, none that constrains the assistant. You verify it all by opening chrome://policy inside the app.


So the sign-in boundary lives on your network. ChatGPT Enterprise documents Workspace Blocking, implemented by "adding a custom HTTP header, ChatGPT-Allowed-Workspace-Id, to your network configuration" carrying workspace UUIDs, comma-separated with no spaces. Personal workspaces are filtered out; a user left with no allowed workspace gets a 403 Forbidden. Then read the next paragraph: "ChatGPT desktop and mobile apps implement certificate pinning," so "you will need to add your own certificates to the pin list, and distribute them to clients via MDM." Header injection only reaches the native app where you have already done that work.


The rest is server-side and plan-dependent. Apps and plugins are "disabled by default" in Enterprise and Edu but "enabled by default" in Business — the single most important sentence for anyone who bought Business assuming it was the cautious choice.


Raycast: the widest control list, almost none of it MDM

Raycast has exactly one MDM hook. MDM Sign-In Enforcement is "Tier: Enterprise Exclusive" and uses managed preferences on bundle id com.raycast.macos with a single key, RequiredSignInDomain, under PayloadIdentifier com.raycast.mdm.requiredsignin. Deployed, Raycast will "Block access to the client until the user logs in with an account matching the required domain" and "Disable the log out option to prevent users from bypassing the enforcement." Raycast publishes a .mobileconfig template — and as with any vendor that ships a sample profile, deploy theirs rather than hand-writing your own.


That is the whole MDM story. Everything else lives in the organization console: SAML SSO, SCIM, Domain Capture, 2FA enforcement, Cloud Sync and Dictation control, an Extensions Allow-List, an IP Allow-List, an organization-wide AI toggle, AI Memory control, bring-your-own-key and an AI Provider Allow-List. The Enterprise product page adds organization-managed MCP servers and "Automated vulnerability scanning," plus the SOC 2 Type II and penetration-test reports your security reviewer will ask for. Pricing is "Custom pricing, billed annually."


All of it is enforced by Raycast's backend, not by the device — which is why the one key that forces users into your org matters most.



Claude Desktop

ChatGPT Desktop

Raycast AI

Preference domain

com.anthropic.claudefordesktop

com.openai.codex

com.raycast.macos

Force org sign-in by profile

Yes - forceLoginOrgUUID

No - network header

Yes - RequiredSignInDomain

Block local MCP by profile

Yes - isLocalDevMcpEnabled

No key documented

No - console only

Block extensions by profile

Yes - one toggle

Yes - Chrome keys

No - console allow-list

Fence the AI on disk

Yes - allowedWorkspaceFolders

No key documented

No key documented

Pin the version by profile

Yes - disableAutoUpdates

No key documented

No key documented

Plan needed for admin control

Team or Enterprise

Mostly Enterprise or Edu

Enterprise, price on request

Documented audit log

Not in the deploy docs

Yes - Compliance API

Not on the pages read

What the profile governs

The assistant itself

The embedded browser

Only who may sign in


What the procurement call will not cover

Raycast's AI privacy page is the most candid document of the three: "We do not log or retain any user prompts. We do store some basic metadata, such as the number of completion tokens, for operational purposes only." Then: "All models provided by Raycast AI are Zero Data Retention (ZDR)... Three exceptions apply." Those are Mistral AI (a rolling 30-day abuse-monitoring window), xAI (30 days before automatic deletion) and, for Claude Fable 5.1, "Anthropic doesn't offer Zero Data Retention for this model. Other Anthropic models remain Zero Data Retention." Your retention posture therefore depends on which model a user picked from a dropdown — which is what the AI Provider Allow-List is for.


One inconsistency I will name rather than resolve: the same page says bring-your-own-key requests to Anthropic, Google and OpenAI "are processed through our servers," and also that when you supply the model yourself "your prompts don't go through Raycast's servers." Both cannot be right as written — get it in writing. Chat history is stored either way, "encrypted in our databases."


OpenAI is the only one of the three with a documented audit trail: for Enterprise, Edu and Healthcare, "workspace admins can access an audit log of conversations and GPTs through the Enterprise Compliance API," alongside AES-256 at rest and TLS 1.2+ in transit. None of the three Raycast pages I read mentions audit logs or data residency, and neither Anthropic deployment article mentions logging. If "show me who asked the AI what" is a compliance requirement, that gap settles the question by itself.


The practical takeaway

Rank these on enforceability rather than trust, because enforceability is the only part you own.


Ship two profiles this sprint. One for com.anthropic.claudefordesktop, setting forceLoginOrgUUID to your org UUID and turning off isLocalDevMcpEnabled, isDesktopExtensionEnabled and secureVmFeaturesEnabled until you have a reason to re-enable each — those defaults are true, and that is not a posture you chose. One for com.raycast.macos setting RequiredSignInDomain, built from Raycast's own template. Both are small and reversible, and together they close the personal-account-on-a-corporate-Mac hole for two of your three clients.


For ChatGPT desktop, deploy the com.openai.codex profile for what it is — browser hardening — and do not let anyone tell the risk committee it manages the assistant. The real boundary is the ChatGPT-Allowed-Workspace-Id header: a network project with a certificate-pinning dependency, not an MDM ticket. Price it honestly.


If someone asks you to standardise on one, say Claude Desktop on a Team or Enterprise plan. It is the only one where a profile constrains what the AI may do on the endpoint rather than merely who may sign in. Raycast is the better answer if your constraint is organisational breadth and you will pay for Enterprise. ChatGPT is the one to treat as an unmanaged browser that happens to be useful: allowed, fenced at the network, and in the monthly inventory report. That is not a knock on the model — it is what the documentation says you can enforce.



Comments

bottom of page