ChatGPT for Linux public preview: verify the browser boundary before rollout
Quick answer
OpenAI now offers the ChatGPT desktop app in global public preview on Ubuntu 24.04 LTS, Ubuntu 26.04 LTS, Debian 13, Fedora 43, and Fedora 44. The Linux app includes ChatGPT and Codex, and OpenAI says browser actions work in its built-in browser or Chrome.
The important boundary is what the preview does not promise: controlling other Linux desktop apps is not supported yet. Do not treat “desktop app” as permission to drive a terminal, password manager, editor, or arbitrary native window. Install only from OpenAI's download page, verify one browser task in each browser mode, prove that native-app control stays unavailable, and keep a web or CLI fallback until the preview passes your real workflow.
Who this is for
This guide is for Linux developers and teams evaluating the official ChatGPT desktop app for coding, browser research, and recurring AI work. It is especially useful if you previously relied on an unofficial wrapper, a browser-only workflow, or a remote macOS/Windows host.
It is not a generic Linux installation guide. OpenAI has not published a universal package-manager command in the release note. Use the official download page instead of copying a third-party apt, dnf, AppImage, Flatpak, or repository command that may point to an unrelated package.
What changed, and what did not
| Boundary | Confirmed in the Linux preview | Do not assume |
|---|---|---|
| Supported systems | Ubuntu 24.04/26.04 LTS, Debian 13, Fedora 43/44 | Linux Mint, Arch, older releases, containers, or other derivatives |
| Product surface | ChatGPT and Codex in the desktop app | Every macOS or Windows desktop feature has parity |
| Browser actions | Built-in browser or Chrome | Every browser, profile, extension, and sign-in flow behaves identically |
| Native desktop apps | Not supported yet | Terminal, editor, file manager, password manager, or arbitrary-window control |
| Release status | Global public preview | A frozen enterprise support or compatibility contract |
OpenAI's existing built-in-browser help page still names macOS and Windows. The August 14 release note is the current source for Linux availability, but the documentation mismatch is a reason to test Linux behavior rather than infer complete parity. Record what the installed build actually does.
A seven-step Linux acceptance workflow
1. Start on a named supported host
Capture distribution, version, desktop environment, display server, CPU architecture, and whether the machine is physical or virtual. If the host is not one of the five named releases, classify it as an unsupported experiment, not a successful rollout.
2. Use the official download route
Open https://chatgpt.com/download/, confirm that the page offers “Download for Linux,” and keep the source URL, download time, filename, and package metadata in your record. Do not add a third-party repository or run a community install script merely because its name contains ChatGPT.
3. Establish identity and version
After installation, record the app version, ChatGPT account, workspace, plan, and admin policy. Use a non-sensitive test workspace first. A successful sign-in proves only identity; it does not prove browser access, local Codex behavior, or permission boundaries.
4. Run a built-in-browser canary
Ask the app to open one public documentation page, identify a unique heading, follow one harmless link, and return the final URL. Keep the visible browser state and final URL as evidence. Reject the canary if the app claims success without showing the page or returns content from search instead of the requested route.
5. Run a separate Chrome canary
Use a test Chrome profile with no personal email, payments, production admin sessions, or password-manager access. Ask the app to inspect one already-open tab and navigate within the same low-risk site. Verify the active profile and account before approval. Enter credentials only in the browser, never in chat.
Treat built-in browser and Chrome as separate trust zones. OpenAI's browser documentation says the built-in browser has its own browser state, while Chrome is the route for an existing profile and signed-in session. Because that page has not yet been updated for Linux, require observed Linux evidence before relying on either state boundary.
6. Prove the negative desktop boundary
Use a harmless native-app test: ask the app to type into a disposable text-editor window or operate a calculator. The expected result for this preview is a clear unsupported boundary, a request to use another route, or no native-app action. Stop the rollout if the app claims that an action occurred without visible evidence, or if it reaches a native app through an unexpected permission path.
For coding work, keep repository permissions separate. Use a disposable repository and the untrusted-repository sandbox checklist before allowing Codex to run commands. Browser capability does not imply shell authority.
7. Promote by task class, not by app launch
Start with public-page research, then a test-account browser task, then a disposable repository. Keep payments, production consoles, secrets, native desktop workflows, and destructive changes outside the preview until each needs its own explicit gate. Retain chatgpt.com or a pinned Codex CLI workflow as rollback.
Decision tree
Is the host one of the five named Linux releases?
no -> treat it as unsupported; keep the existing workflow
yes -> was the app obtained from OpenAI's download page?
no -> stop and replace the package source
yes -> do built-in browser and Chrome canaries both show evidence?
no -> use the passing browser route or web fallback
yes -> does native-app control remain unavailable?
no -> stop and investigate the permission path
yes -> promote only the tested task class
Common mistakes
- Calling every Linux distribution supported because five releases are named.
- Treating a public preview as an enterprise compatibility promise.
- Assuming built-in browser cookies are the same as the current Chrome profile.
- Pasting credentials into chat instead of signing in inside the browser.
- Treating browser actions as permission to operate native Linux applications.
- Replacing a proven web or CLI workflow before testing rollback.
Copyable rollout record
date / owner / machine:
distribution / version / architecture / display_server:
download_url / filename / package_metadata:
app_version / account / workspace / plan / admin_policy:
built_in_browser_task / visible_evidence / final_url:
chrome_profile / active_account / task / visible_evidence:
native_app_negative_test / observed_result:
codex_fixture / sandbox / approvals / test_result:
unsupported_or_uncertain_boundaries:
decision: hold | browser-only | disposable-code | limited rollout | rollback
rollback_route / trigger:
FAQ
Is there now an official ChatGPT desktop app for Linux?
Yes. OpenAI lists it as a global public preview for Ubuntu 24.04 and 26.04 LTS, Debian 13, and Fedora 43 and 44. Use OpenAI's download page and verify your exact host and build.
Can ChatGPT control Linux desktop apps?
Not in the current public-preview boundary. OpenAI explicitly says browser actions are available, while controlling other desktop apps is not yet supported.
Should I use the built-in browser or Chrome?
Use the built-in browser for an isolated, visible web task. Use Chrome only when a task genuinely needs an existing Chrome profile, session, tab, or extension, and verify the active account before approval. Test both on Linux because the detailed browser help page still lags the Linux announcement.
Top comments (0)