TextEdit's Untitled Counter Wasn't Broken — I'd Just Moved the Save Folder

The setup

Open TextEdit. Hit ⌘N. Hit ⌘N again. You expect window titles like:

Untitled
Untitled 2
Untitled 3

Instead, the counter was sticking, names were being reused, and the increment behavior I had taken for granted for years didn't seem to be happening. Nothing was on fire. Nothing was even broken in any way that affected real work. But it was just weird enough to itch, and I made the classic mistake of scratching it before understanding it.

What I can actually say about when it works

The "Untitled N" naming pattern is a long-standing convention in macOS's NSDocument architecture, the framework that sits under document-based apps like TextEdit, Preview, and Pages. As far as I can tell, the specific incrementing behavior of TextEdit's window titles is not officially documented — Apple's developer docs cover the NSDocument autosave machinery thoroughly, but not this surface-level quirk.

What I can report from observation, with no claim to a deeper explanation:

When TextEdit's default save location is the dedicated TextEdit folder inside iCloud Drive — the one that appears automatically when iCloud Drive is enabled for TextEdit — new documents really do increment as Untitled, Untitled 2, Untitled 3, and so on.
When the default save location is anywhere else, the counter doesn't increment in that same persistent way. That includes other folders inside iCloud Drive, like a generic Documents folder synced to iCloud. So this isn't a clean "iCloud Drive turns it on, local disk turns it off" story.

I poked at this a bit and stopped. There are plausible explanations involving the app's own ubiquity container at ~/Library/Mobile Documents/com~apple~TextEdit/Documents/, the way NSDocument treats its dedicated autosave directory, and so on — but I don't have evidence solid enough to commit to a mechanism. The honest version is: the dedicated TextEdit/iCloud folder is the one place where I see this behavior reliably; other locations don't reproduce it; why is left as an exercise for someone with a stronger appetite for AppKit archaeology than mine.

I did not have any of this picture when I started debugging. I just knew the counter was acting strange, and instead of asking the obvious question — "what changed in my setup recently?" — I went straight to suspecting macOS itself. As one does.

The three suspects

I lined up three plausible culprits before touching anything.

Window state restoration. macOS can reopen the windows an app had open last time it quit, controlled by System Settings → Desktop & Dock → "Close windows when quitting an application". If that toggle is off, TextEdit might restore the same Untitled document instead of creating a new one, which would make the counter look frozen.

Auto Save and Versions changing the rules. Since Auto Save and Versions landed in OS X 10.7 Lion back in 2011, TextEdit no longer behaves the way it used to. If you close documents without explicitly saving, rely on next-launch restoration, or live in tabs, the perceived numbering can drift in ways that look wrong but are simply the new normal.

Corrupted saved application state. Occasionally, the per-app state file under ~/Library/Saved Application State/ gets confused, and the simplest fix is to delete it and let macOS rebuild it on next launch.

Three plausible theories, none of them right. Of course.

The fixes I threw at it

Here are the commands, in the order I ran them. None of these are individually dangerous, but defaults delete is the one that turned out to matter — keep reading before you copy-paste it.

# Clear TextEdit's saved window/restoration state
rm -rf ~/Library/Saved\ Application\ State/com.apple.TextEdit.savedState

# Reset all of TextEdit's preferences to defaults
defaults delete com.apple.TextEdit

# Globally tell macOS not to keep windows on quit
defaults write -g NSQuitAlwaysKeepsWindows -bool false

# To revert that later:
defaults delete -g NSQuitAlwaysKeepsWindows

After running those, I quit TextEdit, restarted the Mac for good measure, and tried again.

It worked.

The punchline

It worked, but not for any of the reasons I had hypothesized.

The fix that mattered was defaults delete com.apple.TextEdit. Not because it cleared some corrupted state, and not because it untangled window restoration. It mattered because that one command reset every TextEdit preference, including the remembered "where to save" location.

Worth a small detour here: TextEdit doesn't actually expose a "default save location" setting in its Settings window. There is no such checkbox or dropdown to find. Instead, TextEdit silently remembers the Where value from the last File → Save… dialog, and uses it as the starting location next time. Save once into ~/Documents and from then on, ~/Documents is the default. Save into iCloud Drive's TextEdit folder and that becomes the default. It's the standard macOS NSSavePanel behavior, persisted per app via defaults.

Some weeks earlier, I had saved a one-off note into a different folder, which quietly promoted that folder to "the place TextEdit saves things now." With the defaults wiped, that memory was gone, and TextEdit fell back to its true factory default: the TextEdit folder inside iCloud Drive. And that, empirically, is the one place where the Untitled counter behaves the way I remembered. The "starts working again" effect was just the save target returning to the only location that exhibits the behavior, for whatever reason.

The counter was never broken. The remembered save location had drifted, the visible behavior had changed with it, and I had spent the better part of an evening writing Terminal incantations to cure a non-disease. The reboot did nothing useful either, except give me a satisfying sense of having "really" reset things.

If I had simply hit ⌘S on a new document and looked at the Where field in the save sheet, this post would not exist.

The short version

TextEdit's "Untitled N" counter looked stuck.
I cleared saved application state, reset defaults, toggled NSQuitAlwaysKeepsWindows, and rebooted.
The counter started incrementing again.
The reason: defaults delete com.apple.TextEdit wiped TextEdit's memory of the last-used save location, and the next launch fell back to the factory default — iCloud Drive's dedicated TextEdit folder. That specific folder is, empirically, the only place where I see the Untitled counter behave this way. Other locations, including other iCloud Drive folders, don't reproduce it. I do not have a confident explanation for why; just the observation.

A few things worth internalizing

The Untitled-N-counter behavior is tied to where TextEdit thinks it should save, not to TextEdit-as-an-app in the abstract. Specifically, it shows up reliably when the dedicated TextEdit folder inside iCloud Drive is the default save location, and not when other folders — including other iCloud Drive folders — are. There's no documented contract here; treat it as observed behavior, not as a feature you can rely on.
When a system "magically starts working" after a reset, the most useful question is which side effect of the reset actually mattered. "I ran three commands and it worked" is not a diagnosis. It is just a story.
Resetting an app's defaults is one of those moves that sounds surgical but isn't. It quietly returns the app to a configuration that may differ from what you have been working with for months. Sometimes that is the fix. Sometimes that is the bug.
And the boring meta-lesson: before reaching for rm -rf or defaults delete, check what the app is actually doing. For TextEdit that meant pressing ⌘S and looking at the Where field — not opening a settings pane, because the relevant setting doesn't live there. State that's persisted invisibly via defaults is just as real as state shown in a UI, and easier to forget about.