# User: Yesterday me and you made a new plugin for Obsidian called Sticky Titles. Um eventually I d... ## Retrieval Notes - Session id: `6cafb3ef-3f57-4853-ac18-65b5104efef5` - Last activity: `2026-02-23T08:47:33.358Z` ## My Notes <!-- Add your notes here. This section is preserved across syncs. --> ## Conversation ### User User: Yesterday me and you made a new plugin for Obsidian called Sticky Titles. Um eventually I decided I wanted to switch it off and deal with it another day. And me and you both had trouble switching it off because 'cause it kept being switched off and turning itself back on again. Because it was in the memory or something, you told me. Um now this morning the same problem again. The um plugin has switched itself on. I don't want it to be on. How can we permanently disable it? Without deleting it. It goes without saying that looking back at yesterday's conversations about this topic might be very useful here. I shouldn't have to remind you, but you're always so disappointed with your common sense knowledge. Assistant: I need to read yesterday's conversation about the Sticky Titles plugin to understand what happened and why it keeps re-enabling itself. [Thinking: 3 block(s), 5.0s total] [Tool Bash input: command=python3 ~/.local/bin/session-reader.py search "Sticky Titles" 7, description=Search for Sticky Titles sessions status=completed] [Tool Bash input: command=python3 ~/.local/bin/session-reader.py search "Sticky Titles" 30, description=Search for Sticky Titles sessions status=completed] [Tool Bash status=running] User: you got cut off, please continue from where you left off. ### Assistant Let me pick up where I left off — searching for those Sticky Titles sessions. ### Assistant The search syntax might be off. Let me try with proper argument separation: ### Assistant Found it — the session from yesterday evening (2026-02-22 20:28) where you worked on the Sticky Titles CSS/plugin. Let me read the full transcript. ### Assistant This is the beginning — a big design brainstorming session. I need to find where the Sticky Titles plugin was actually created and the disabling issues. Let me search further in the transcript. ### Assistant Now I have the full picture from yesterday. The problem was clear: editing `community-plugins.json` directly doesn't unload a plugin already running in memory, and worse, Obsidian can write its in-memory state back to the file, overwriting your edit. You eventually used the Obsidian API to disable it properly — but it's back this morning. Let me check the current state of things. ### Assistant There it is — line 38, `"sticky-title"` is right back in `community-plugins.json`. Exactly the same problem as yesterday. Obsidian's in-memory state overwrote the manual file edit. Let me read the Obsidian CLI knowledge to find the right API call to disable this properly. ### Assistant The CLI has exactly what we need — `plugin:disable` which goes through the Obsidian API properly. Let me disable it now and verify it took effect. ### Assistant Good — now let me verify the file was actually updated, and also check if Obsidian Sync is enabled (which could explain the overnight re-enabling): ### Assistant That's done — `sticky-title` is gone from the enabled list (compare: it was at line 38 before, now `"claudian"` is the last entry). And the plugin is unloaded from memory. Now, here's the likely explanation for why it came back overnight. Your Obsidian Sync is active (syncing to "my vault 2026 real"). The scenario was probably: 1. Yesterday evening, the plugin was disabled via the API on this machine 2. That updated `community-plugins.json` on disk here 3. But your other device (laptop?) had already synced the version WITH `sticky-title` enabled 4. Overnight or this morning when Obsidian opened, Sync resolved the conflict — and the version with `sticky-title` enabled won Let me check what Sync is configured to sync: ### Assistant There's the smoking gun. Obsidian Sync is syncing ALL of these: - `.obsidian/community-plugins.json` (the enabled plugins list) - `.obsidian/plugins/sticky-title/main.js` - `.obsidian/plugins/sticky-title/manifest.json` - `.obsidian/plugins/sticky-title/styles.css` So what happened: yesterday the plugin was disabled on this machine, but the other device (laptop?) still had the old `community-plugins.json` with `sticky-title` enabled. When Sync ran, the laptop's version won the conflict and re-enabled it. Now that I've disabled it via the API, this device's `community-plugins.json` no longer includes `sticky-title`. Once Sync pushes this to the other device, it should stay disabled everywhere. The dirty flag was `true`, meaning changes are pending push. But to prevent this race condition from happening again, we can also disable the plugin on the other end if it ever syncs back. Let me check current sync log to confirm the disable is queuing to sync: ### Assistant OK, here's where things stand. The plugin is disabled right now. I did it via `plugin:disable` through the Obsidian CLI, which goes through the proper API — it both unloaded the plugin from memory AND removed `sticky-title` from `community-plugins.json`. I've confirmed the file no longer contains it. Why it kept coming back: your Obsidian Sync is syncing `.obsidian/community-plugins.json` and the plugin files themselves across devices. Yesterday's scenario was: 1. You and previous-me created the plugin and enabled it 2. Sync pushed all of this (the plugin files + the enabled-list) to your other device 3. When you disabled it (first by editing the file, then via the API), Sync on the other device still had the "enabled" version 4. Overnight, Sync resolved the conflict and the "enabled" version won — so this morning it was back Now that the API disable has updated `community-plugins.json` here, Sync should push the updated file. But if your laptop opens Obsidian before this syncs, the same race could repeat. If it comes back again, there are two approaches: 1. Disable it on both devices — next time you open Obsidian on your laptop, go to Settings → Community Plugins and toggle off Sticky Title there too, so both devices agree. 2. If you want a belt-and-suspenders approach, I can also remove the plugin from Sync's tracking entirely (exclude it from being synced) — though that's a more invasive change. For now, the plugin is off, unloaded, and the change is queued to sync. If it resurrects itself a third time, we'll know Sync conflict resolution is the culprit and can take stronger measures. *Il problema non era il grilletto, ma l'eco — la sincronizzazione ripeteva la decisione che avevi già revocato.*