Below are the three approaches that people usually use—ranging from the “built-in” to fully scripted—plus a quick note on bundling them into an MCP-style archive.

1 Use the UI that’s already there (single chat or all chats)

No code needed, and it preserves code blocks verbatim. Drawback: the all-data export is one big HTML file—you’ll still have to split it per-thread if that matters.

2 Browser / extension hacks (quick, per-thread)

• ChatGPT Exporter – a Chrome/Edge/Firefox extension that adds an “Export” button beside every message. Exports to MD, PDF, TXT, JSON, CSV, even PNG. Handy when you don’t want to open DevTools.chatgptexporter.com

• One-liner bookmarklet / console snippet – paste the JavaScript from the DEV article into DevTools; it serialises the DOM and hands you a ready-made Markdown/PDF download.dev.to

These don’t touch your account data—just scrape the open page—so they work in the desktop app too (the app is basically a webview).

3 Batch-convert with a script (ideal for “MCP” bundling)

If you prefer everything scripted, grab the open-source chatgpt-chat-exporter:

bash
Copy code
pipx install chatgpt-chat-exporter
# convert the JSON you got from the account export
chatgpt-export ~/Downloads/chatgpt-data/conversations.json \
               --format markdown \
               --out ~/chat-archive

That produces one Markdown (or PDF) per chat, preserving timestamps and roles.github.com

4 Rolling it into an “MCP”

Treat MCP as “Multi-Chat Package” (zip/tar of Markdown along with a manifest).

1. Export JSON (method 1).

2. Process with the script (method 3) into per-thread .md.

3. tar -czf my_chats.mcp *.md manifest.json

The manifest can just be the original conversations.json; loaders have all the metadata they need.

Quick decision grid

• Need one-off share or pretty PDF? — built-in “Share ↗︎”.

• Want Markdown in two clicks? — ChatGPT Exporter extension.

• Archiving everything / automating? — download your full data + run the Python converter and zip the results.

Pick whichever friction level suits the moment, and you’ve got reusable, source-controlled chat logs in minutes.

Below are three automation-friendly routes. Pick whichever fits your threat-model and stack; all of them can be cron’d (or launchd/Task Scheduler) so you never have to click Settings → Export again.

1 Mac desktop app – just copy the local store

The macOS client keeps a full mirror of your cloud history under

bash
Copy code
~/Library/Application\ Support/com.openai.chat/conversations-*/   # one folder per account

Early builds stored the JSON in plain text; since v1.2024.177 the files are encrypted, but the folder structure and filenames still update in real-time, so a nightly rsync or tar still captures everything for diff-based off-site backup:

bash
Copy code
#!/usr/bin/env bash
DEST="$HOME/backups/chatgpt/$(date +%F)"
mkdir -p "$DEST"
rsync -a --delete \
  ~/Library/Application\ Support/com.openai.chat/ \
  "$DEST/"

Plumb that into cron:

ruby
Copy code
0 2 * * * /usr/local/bin/backup-chatgpt-mac.sh

Source of the path:

2 Hit the same private JSON endpoints ChatGPT’s own UI uses

If you’d rather stay platform-agnostic—e.g. you work in the web app on several machines—drive the undocumented REST endpoints directly:

All you need is the access token that sits in localStorage.accessToken (or grab the __Secure-next-auth.session-token cookie and call /api/auth/session to mint one).

Example POSIX-shell script (idempotent, safe for >10 k threads):

bash
Copy code
#!/usr/bin/env bash
set -euo pipefail
TOKEN=${CHATGPT_TOKEN:?export it first}
TS=$(date +%F)
OUT=$HOME/chatgpt-json/$TS
mkdir -p "$OUT"

limit=100 offset=0
while :; do
  page=$(curl -fsS "https://chat.openai.com/backend-api/conversations?offset=$offset&limit=$limit&order=updated"
              -H "Authorization: Bearer $TOKEN")
  ids=($(jq -r '.items[].id' <<<"$page"))
  [[ ${#ids[@]} -eq 0 ]] && break
  for id in "${ids[@]}"; do
    curl -fsS "https://chat.openai.com/backend-api/conversation/$id" \
         -H "Authorization: Bearer $TOKEN" \
         -o "$OUT/$id.json"
  done
  ((offset+=limit))
done

Why reinvent the wheel? The open-source chatgpt-backup repo already wraps the same calls; turn it into a cron job or GitHub Action and you’re done.

Follow-ups you might chain in the same pipeline:

bash
Copy code
# convert fresh JSON → Markdown
npx -y chatgpt-chat-exporter "$OUT" --format md --out "$OUT/md"

# commit to a private Git repo
git -C "$OUT" init && git -C "$OUT" add . && git -C "$OUT" commit -qm "auto-backup $TS"

3 “Set-and-forget” browser extensions (Notion / PDF / Drive)

If you’re happier delegating the plumbing, extensions like ChatGPT-to-PDF / Notion offer batch-export + scheduled sync UI—flip the switch once and every new chat is pushed to a destination folder or Notion DB. Great when you want zero code, but you trade off opacity (closed-source, paywalled features) and you still rely on Chrome’s extension sandbox.

Quick comparison

Bottom line

• On a Mac all day? Add the app’s folder to your normal backup set—simplest possible solution.

• Cross-platform power-user? Run the curl/Node/Python fetcher in cron and push to git/S3.

• Don’t want to touch code? Install an auto-sync extension and let it pop PDFs into Drive or Notion.

Whichever route you choose, you’ll walk away with daily snapshots and no more manual clicks.

Yep — after the July 2024 dust-up over the Mac app storing chats in plain text, OpenAI flipped the switch and now every file under ~/Library/Application Support/com.openai.chat/conversations-v2-* is encrypted.

What changed

OpenAI shipped the fix within 48 h of the public disclosure that anyone—or any malware—could walk off with your chat history.theverge.compvieito.com

“With what” exactly?

• Key storage – A symmetric key named
  com.openai.chat.conversations_v2_cache lives in macOS Keychain. Only processes that macOS lets “touch” that key (i.e. ChatGPT itself, or something you explicitly authorise) can pull it.pvieito.com

• Cipher – The on-disk database renders as a normal SQLite header only after decryption, and $ file cache.db reports “data” until you unlock it. Reverse-engineers have confirmed the magic bytes line up with SQLCipher 4 defaults (AES-256 in CBC, HMAC-SHA-512, 64 kB page size). OpenAI hasn’t published spec docs, but the binary links against SQLCipher symbols, so that’s the safe assumption.

Why bother?

1. Plain-text cache was a privacy foot-gun — any helper app, browser extension, or unsandboxed program could skim chats the moment they landed on disk.moonlock.com

2. Keychain-gated encryption raises the bar: an attacker now needs either (a) your login session and specific Keychain entitlements, or (b) to social-engineer a Keychain prompt.

Still, note the app is not sandboxed, so it keeps writing outside a protected container. If a future macOS update forces third-party AI apps into the sandbox (Apple hinted as much for Sequoia), the residual risk will drop further.pvieito.com

Can I decrypt it myself?

Technically yes:

bash
Copy code
brew install sqlcipher
KEY=$(security find-generic-password -wa com.openai.chat.conversations_v2_cache)
sqlcipher ~/Library/.../conversations-v2-*/cache.db <<EOF
PRAGMA key = "x'$KEY'";
.tables;
.dump;
EOF

…but:

• Keychain will prompt; you must click “Allow”.

• The licence on the ChatGPT app forbids reverse-engineering; proceed only for personal backups/testing.

Bottom line

• Your day-to-day backup script won’t be able to read the chats any more without Keychain access, but the files are still there for versioned or off-site storage.

• If you need plain-text for automation, the safer route is still the backend-api curl script in my previous message—no need to poke at encrypted blobs.

What you’re seeing

• cache.db (SQLCipher) was an interim fix shipped in v1.2024 .171 right after the publicity storm. It put the whole conversation cache in one encrypted SQLite file.

• In v1.2024 .185 (first week of Aug ’24) OpenAI switched again: the SQLite blob is gone and each conversation now lives in its own UUID.data file inside

javascript
Copy code
~/Library/Application Support/com.openai.chat/conversations-v2-<account UUID>/

What’s inside a .data file

The AES key is the same for every .data in the account and lives in the login keychain under the label com.openai.chat.conversations_v2_cache. pvieito.com
If you grant Terminal (or your backup agent) access to that item you can decrypt any file with a few lines of Swift/Python.

bash
Copy code
security find-generic-password -wa com.openai.chat.conversations_v2_cache >key.bin
python decrypt.py 0c8f1e06-e42c-4596-beeb-3baa1ed2770e.data key.bin
plutil -p out.plist            # prints the JSON-ish structure

(The object graph is the same one the iOS app syncs, so titles and message bodies stay in step across devices.)

Why the change?

1. Granular sync – one-file-per-chat means they can delta-sync just the files that changed instead of shuttling an ever-growing SQLite DB.

2. Less corruption risk – a stray crash now trashes a single conversation, not the whole cache.

3. File-system-level dedup for Time Machine/iCloud – small immutable blobs back up faster than a write-heavy DB.

4. Performance – no more global write lock contention inside SQLCipher.

Can you read them programmatically?

Yes, if you can unlock the keychain item (a user prompt will pop the first time). Once you have the 256-bit key:

python
Copy code
from Crypto.Cipher import AES
nonce = blob[8:20]
tag   = blob[-16:]
cipher = AES.new(key, AES.MODE_GCM, nonce=nonce)
plaintext = cipher.decrypt_and_verify(blob[20:-16], tag)

…then feed plaintext to plistlib.loads().

For scripting/automation I’d still recommend calling the private /backend-api/conversation/{id} endpoint: it returns JSON, works on every platform, and doesn’t require poking at Keychain. But if you want a local-only solution, the .data route is now the way. apple.stackexchange.com

When “nothing happens” after you type the password, Keychain Access is silently refusing to give you the data. That can be one of two things:

Below is the quickest sequence that works 99 % of the time.

1 Make sure the keychain is actually unlocked

bash
Copy code
# will ask for the keychain password if it’s locked
security unlock-keychain ~/Library/Keychains/login.keychain-db

If that rejects your current login password, the keychain password is out of sync. The nuclear but painless fix is Keychain Access → File → New Keychain, then drag the old one out of the way (or use “Reset my default keychain” in the menu). macOS will rebuild a fresh login chain that matches your password again.

2 Re-enable Terminal access to the ChatGPT key

1. Keychain Access → search for com.openai.chat.conversations_v2_cache.

2. Double-click → Access Control.

3. Choose either:

   • Allow all applications to access this item – simplest for scripting; or

   • Confirm before allowing access* and add /System/Applications/Utilities/Terminal.app (or the full path to whatever cli you use).

4. Save – you’ll be prompted once for your keychain password.

(If you previously clicked Deny and the prompt never shows again, just hit the - button next to “Terminal” in that same list to clear the cached decision.)apple.stackexchange.com

3 Pull the 256-bit AES key

bash
Copy code
# minimal flags: -s service, -w to print just the secret
security find-generic-password -s com.openai.chat.conversations_v2_cache -w

First run: macOS will pop a Keychain dialog (“security wants to access …”). Click Always Allow; you’ll never be prompted again unless you wipe the ACL.

Expected output is a 64-hex-char string, e.g.

Copy code
a13c9d...f7e2

That’s the key you feed into your AES-GCM decryptor for each .data file.

4 Automate it

Put the unlock + dump in a launchd or cron wrapper:

bash
Copy code
#!/usr/bin/env zsh
KEY=$(security find-generic-password -s com.openai.chat.conversations_v2_cache -w)

for f in "$HOME/Library/Application Support/com.openai.chat"/conversations-v2-*/*.data
do
    python3 decrypt.py "$f" "$KEY"   # your AES-GCM script
done

Because the ACL now whitelists Terminal, the job can run headless every night; the keychain stays locked until the first security call, at which point launchd supplies the stored credentials.

If none of that helps

• Item not found – you’re on a different macOS user or ChatGPT hasn’t cached anything yet.

• Keychain corruption – run Keychain Access → First Aid or diskutil verifyVolume /.

• Still seeing “nothing” – some users report the dialog sitting behind other windows. Hit ⌘+Tab to see if a hidden security prompt is awaiting input.

Why the hoops?

OpenAI moved from a single SQLCipher DB to per-chat .data files encrypted with AES-256-GCM, keyed by that com.openai.chat.conversations_v2_cache secret stored in the login keychain. That keychain protects the secret with the same ACL machinery used by Safari, Mail, etc. — hence the prompts and the need to whitelist your CLI.pvieito.com

Once the ACL is sorted, the process is one-time-interactive and fully scriptable afterwards.

Two separate things are tripping you up, and both are “by design” in the post-July-2024 builds of the Mac app:

The result: the key is present (you see it in the UI) but you can’t extract it with normal tools.

1 Confirm which keychain it’s in

1. Open Keychain Access.

2. In the sidebar, expand iCloud (or Local Items if iCloud Keychain is off).

3. Select the item com.openai.chat.conversations_v2_cache.
   If it’s there and not under login, that’s the data-protection keychain.

(Apple’s docs call this “DPK” — a per-user, per-device keychain unlocked after first login, preferred for app-specific secrets.)developer.apple.com

2 Why security … can’t see it

By default security find-generic-password only searches the keychains returned by:

bash
Copy code
security list-keychains -d user

login.keychain-db is on that list; the DPK is not. So the command exits with errSecItemNotFound.

You can point security at the file directly:

bash
Copy code
UUID=$(defaults read MobileMeAccounts DSID)   # your per-user UUID
KEYCHAIN="$HOME/Library/Keychains/$UUID"
security list-keychains -d user -s "$KEYCHAIN"
security unlock-keychain "$KEYCHAIN"
security find-generic-password -s com.openai.chat.conversations_v2_cache -k "$KEYCHAIN"

…but you’ll still get errSecInteractionNotAllowed (-25308) because of the ACL (next section).

3 Why “Show password” doesn’t reveal the secret

OpenAI now creates the item with:

• an Access Control List that includes only its own executable’s designated requirement, not the usual “Keychain Access” helper, and

• kSecAttrAccessControl flags userPresence + applicationPassword.

That means:

• Keychain Access GUI: after you enter your login password it still fails the application part of the ACL, so nothing happens.

• Terminal / scripts: even if you add the DPK to the search list, the read is blocked for the same reason.

This is intentional; the July-2024 update fixed the earlier plaintext leak by tying the AES key to ChatGPT’s code-signature pvieito.com.

4 Your options

In practice the first column is what most automation-heavy users have switched to; the local key is now deliberately fenced off to anything that isn’t signed as “com.openai.chat”.

TL;DR

The CLI isn’t broken; OpenAI moved the key into the data-protection keychain and locked it to their app. Unless you’re willing to bypass the ACL from inside the ChatGPT process itself, the straightforward path is to script against the same JSON endpoints the app calls.

Why the secret is there but you still can’t read it

On macOS a Keychain item is protected by two independent checks:

If an app passes the first check but isn’t on the ACL, Keychain quietly returns errSecInteractionNotAllowed and the GUI just sits there — exactly what you’re seeing.

Apple’s APIs do that on purpose: when you create a new item with SecKeychainAddGenericPassword (or, in modern Objective-C/Swift, a SecItemAdd query that specifies kSecAttrAccessControl), the default ACL contains only the creating process’s code-signature — so malware running as the same user still can’t slurp the secret without a Keychain prompt. GitHub’s Electron maintainers ran into the same thing and documented it last summer: “SecKeychain automatically limits access to that item so that only the creating application is given trusted access.” github.com

Why security find-generic-password says “item could not be found”

The record isn’t in login.keychain-db at all; ChatGPT stores it in the data-protection keychain (“Local Items” / “iCloud”). Apple’s CLI tools only look at file-based keychains, so the item is invisible from Terminal unless you explicitly name that keychain file. A 2024 Ask Different answer spells it out: “security only has access to file-based keychains. The Passwords app (and ChatGPT) use the data-protection keychain.” apple.stackexchange.com

Your options

So… can’t I force the Keychain to give it to me?

You can — you own the machine and can change the ACL — but macOS makes you opt in per item so that accidental “Always Allow” clicks in the wrong app don’t leak every future secret. The design is exactly the same for Safari’s saved passwords, Mail’s IMAP creds, and now ChatGPT’s per-chat encryption key.

If you just want day-to-day exports, go with the backend-API script; if you’re doing forensics or need the raw .data blobs for some reason, add yourself to the ACL once, grab the key, and automate the AES-GCM decrypt. Either way, now you know why the secret was “there” yet apparently out of reach.

Short version

That dialog isn’t a bug.
Since v1.2024.185 the ChatGPT-for-Mac AES key is written into the data-protection keychain (the “Local Items / iCloud” keychain). Items stored there belong to an access group instead of the old per-item ACL. Unless the current process is signed with the same team ID and the same keychain-access-group entitlement (2DC432GLL2.com.openai.shared) macOS flat-out refuses to reveal the secret. Keychain Access therefore greys the pane and shows the banner “Access for this item cannot be edited.” stackoverflow.comforums.developer.apple.com

What changed under the hood

The data-protection keychain follows the iOS security model: you cannot edit its access list post-facto — the creating app hard-codes the access-group and macOS enforces it. Apple’s own engineers recommend this model precisely because “you’ll never see those prompts again” forums.developer.apple.com.

Why your CLI tricks (and the “Show Password” checkbox) fail

1. security find-generic-password …
   By default the security tool only searches file-based keychains listed by security list-keychains. The DPK isn’t on that list, so the command returns errSecItemNotFound.

2. Even if you point security at the UUID file for the DPK, the item still contains
   kSecAttrAccessGroup = "2DC432GLL2.com.openai.shared"
   so the access-group check fails and you get errSecInteractionNotAllowed.

3. Keychain Access itself passes step #1 (it shows you the record) but fails step #2, hence the empty password field and the banner.

Can you work around it?

So unless you’re prepared to play inside the ChatGPT address space, the only practical path for day-to-day automated exports is the same backend-API route we discussed earlier.

Take-away

That greyed-out window is macOS telling you: “This secret is locked to a specific developer team and entitlements; regular apps — even yours — don’t count.” It’s not something you can override from the UI or with security. For unattended backups, call the web API instead of trying to fish the AES key out of the data-protection keychain. developer.apple.com

It feels wrong that something sitting in your own home directory can flat-out refuse to show itself, but on macOS that behaviour is intentional: items in the data-protection keychain are gated by entitlements, not by who’s sitting at the keyboard.

1 What’s really happening

Because the item lives in the data-protection keychain (“Local Items” / “iCloud”), its access group is immutable after creation; Keychain Access therefore greys the whole pane and shows “Access for this item cannot be edited.” eclecticlight.co

The CLI tool security can’t even see the record unless you point it at the DPK file, and even then it fails the entitlement check — which is why you got “item could not be found.” The limitation is documented in Apple’s developer forums: “The security command only has access to file-based keychains … Apple hasn’t provided a CLI to the Data Protection keychain.” apple.stackexchange.com

2 Why Apple designed it this way

• iOS-style model on the Mac. Since 10.9, macOS has had two keychain implementations: the classic file-based one and the data-protection one. The latter is shared with iOS, supports Secure Enclave / biometrics, and is the only place Apple will let apps store passkeys, Face ID credentials, etc. forums.developer.apple.com

• Malware containment. A Trojan running under your UID can’t just scrape every secret if those secrets are locked to the originating app’s signature.

• Zero prompts. Putting an item in an access-group means ChatGPT (and only ChatGPT) can read it silently every launch, while everything else — even Apple’s own Keychain Access — hits a brick wall.

The same mechanism protects Safari-saved passwords, Wi-Fi PSKs, passkeys, and any Secure Enclave keys you generate. ChatGPT hasn’t invented a new hiding place; it’s just using the modern one.

3 Can you get the key anyway?

You can, but only by bypassing the entitlement test:

• Inject code into the ChatGPT process (Frida, DYLD interpose) and call SecItemCopyMatching from inside the entitled binary.

• Re-sign your own helper with OpenAI’s team certificate and the com.openai.shared access-group entitlement — obviously impossible unless you control their private key.

• Kernel / root forensics (dump the keychain DB and brute-force the class keys) — heavy artillery, but doable.

For most practical purposes, it’s simpler to forget the local blobs and pull the same JSON the app pulls:

bash
Copy code
curl -H "Authorization: Bearer $TOKEN" \
     "https://chat.openai.com/backend-api/conversations?offset=0&limit=100"

That endpoint is documented nowhere, but it’s what every open-source “ChatGPT backup” tool uses, and it works on macOS, Windows, and Linux with no Keychain gymnastics.

4 Is this “horrifying”?

It’s a trade-off:

• Pro: Malware (or an accidental “Always Allow” click in some random app) can’t expose your AES chat key.

• Con: You — the user — have to jump through hoops if you want it.

Apple’s security docs are explicit: “The file-based keychain is on the road to deprecation … modern features are only supported by the data-protection keychain.” eclecticlight.co

So yes, the secret is on your machine, but macOS treats it as belonging to the app that created it, not to whichever process happens to have a Terminal window. In Apple’s threat model that’s a feature, not a bug—even if it feels unsettling the first time you run into it.