When a ChatGPT sync bug made my Mac the source of truth

When ChatGPT projects stopped matching across clients

ChatGPT added projects and I moved real work into them. Threads grouped by project, some of them long and important, some of them things I actually needed to find again.

Then the sync broke.

On the desktop app, my project threads were there. On the web, the same projects looked half empty, missing recent messages or whole threads. Sometimes a thread would appear with an old state, as if the last few hours never happened. Sometimes it simply refused to show up outside the Mac app that created it.

This was not an outage. The model worked. The desktop app worked. The bug lived in the sync between the native app and the web client.

That is also the line between a nice client and a vendor quietly owning your workflow.

Native app bugs as soft lock-in

Traditional vendor lock-in is about data formats and APIs. You can export your data, or you cannot. You can script around a tool, or you cannot. With AI tools, there is a quieter version: the client that holds a slightly different reality than the server, and the sync bug that never quite reaches the top of the backlog.

When the ChatGPT desktop app and the web UI disagree about what exists, you effectively get two products:

• The one on your Mac, with the real conversation history.
• The one in your browser, with a partial copy.

If the only place where the full, usable state of your project lives is a native app on a single machine, that machine becomes the product. You do not just rely on OpenAI; you rely on that specific Mac staying healthy, backed up, and physically reachable.

That is a strange kind of lock-in. It is what happens when a native app gets features that the web client cannot quite mirror, and the sync layer is treated as something less than critical infrastructure.

I wrote about this earlier in What Six Months of Daily Weigh-ins Can and Cannot Prove.

When "just use the web" stops being an option

In theory, the web version of a tool is the neutral ground. If the Mac app misbehaves, you open a browser and keep working. That only works if the browser sees the same state.

With the project threads out of sync, that fallback disappeared. I could not simply move to another machine, open chatgpt.com, and pick up the same project. The project existed, but the important context did not. That is the moment a bug turns from annoying into structural.

For a paid product, this matters more. A premium plan is not just about faster models or extra features; it is a promise that you can treat the tool as part of your stack. If the web client cannot be trusted to show the same reality as the desktop app, that promise gets weaker.

Using a remote Mac as the source of truth

Once it was clear that the Mac app and the web client disagreed, the only reliable copy of some project threads lived on one machine. That pushed me toward a simple workaround: treat that Mac as the canonical interface and reach it remotely instead of trusting the web client.

The basic idea:

• Leave a MacBook Air at home with the ChatGPT desktop app open.
• Use Tailscale to get a private, stable network path to that Mac from elsewhere.
• Use macOS Screen Sharing to remote into that Mac and use ChatGPT inside its desktop app, as if I was sitting in front of it.

No exports, no API, no sync. Just pixels from the one machine that still had the correct state.

VNC vs Remote Management on macOS

On macOS, Screen Sharing is essentially a VNC client. Under the hood there are two relevant knobs:

• Screen Sharing / Remote Management in System Settings, which controls whether the Mac accepts remote control.
• VNC compatibility, which lets you connect with generic VNC clients if you enable it and set a password.

The distinction matters because Remote Management is aimed at device management tools and can expose more than you actually need if you are just trying to click around your own desktop. Plain Screen Sharing is usually enough, especially when you are already on a private Tailscale network.

More on this in my article The Tower Workflow That Keeps My Mac Studio And MacBook Air Perfectly In Sync.

Tailscale handles discovery, NAT traversal, and encryption. Once both devices are in the same tailnet, the Screen Sharing app can connect to the MacBook Air using its Tailscale IP or name, and you get a remote view of the desktop. From there, the ChatGPT app is just another window.

Why this feels wrong for a web-first product

This setup works, but it should not be necessary. The whole point of a web app is that your data lives on the server and any client is a view on that same state. When the server becomes just one interpretation and the native app becomes the real source, the model flips.

For conversation tools, that flip is dangerous. Chats are not static documents. They are stateful objects that influence future outputs. If a project thread is missing the last 20 messages in one client, asking a follow-up question there is not just inconvenient; it is running a different experiment with a different prompt history.

That is why the idea that web apps should not hold your conversation data hostage is not just about exports. It is about:

• Having a single, consistent source of truth for conversation state.
• Making sure every official client is an honest window onto that state.
• Letting people move between devices without guessing which one is canonical.

If the only reliable way to access the correct state is to remote into a specific Mac, you are not really using a cloud service anymore. You are running a thin client to a personal appliance that you do not fully control.

Premium plans raise the bar

When you pay for a service like ChatGPT, you are not just buying tokens and features. You are buying predictability. That includes:

• Projects and threads existing in one coherent place.
• The web client being trustworthy as a backup and a primary interface.
• Native clients that can come and go without trapping your work.

Sync bugs will happen. The problem starts when they linger long enough that people begin to build infrastructure around them: remote desktops, backup scripts, odd export workflows. Once that happens, a bug has effectively become product behavior.

Read also Replacing Three Client Dashboards With One Local n8n.

At that point, the native app is not just a nicer window. It is a dependency. And because the vendor owns that app, the bug becomes a quiet form of lock-in. You could leave, in theory. In practice, your live projects are entangled with a specific binary on a specific box.

What less lock-in would look like

There are a few obvious ways this could be less fragile:

• The server is always the source of truth for project state, and every client is forced to reconcile with it, even if that means occasionally discarding local changes.
• The web client is treated as the reference implementation. Native clients can add convenience, not unique features or data shapes.
• Exports for conversations and projects are easy, structured, and complete, so you can keep your own archive or move key threads elsewhere.

None of this is glamorous. It does not show up in release notes as nicely as a new model. But without it, people end up tunneling pixels from a laptop that accidentally became the only honest copy of their work.

That is a new shape of vendor lock-in: not just proprietary formats and missing APIs, but quiet bugs in native clients that make one window more real than the others.