AI skill selection is never persisted - Manage Skills toggles reset on restart (6.640 and 6.687);

Enabling skills in AI ConfigurationManage Skills works for the current session, but the selection is lost as soon as BetterTouchTool restarts. Every skill returns to its default state and has to be re-enabled.

The interesting part: the underlying mechanism works fine - it seems to be only the UI's save path that is missing.

If I write BTTAIActiveSkills directly into an assistant's BTTAdditionalDataJSON (via add_new_trigger), the key persists across restarts and is honoured - the tool set visible to that assistant changes accordingly. With ["safari_automation"] the assistant drops to 0 tools; with a list of guessed ids it came back with 4 (run_javascript, sequential_thinking, web_fetch, web_search). So BTT reads the key correctly. The Manage Skills UI simply never writes it.

When toggling in the UI instead, nothing is written anywhere I could find:

  • no BTTAIActiveSkills / BTTAIOptionalSkills / BTTAIDisabledSkills key appears in the assistant's BTTAdditionalDataJSON
  • no ~/Library/Application Support/BetterTouchTool/AI/Skills/ directory is ever created
  • nothing in index.db, function_library.sqlite or memory.db
  • no matching key in com.hegenberg.BetterTouchTool

I think this is the same thing cornelius reported in h@llo.ai - Upcoming AI Features post #115 back in April ("any changes to the toggles there don't seem to be saved after closing that panel"), which does not seem to have been picked up since.

Could you post the list of built-in skill ids? Only safari_automation appears as a plain string in the binary. With the correct ids, writing BTTAIActiveSkills directly would be a usable workaround until the UI saves properly.

Possibly related: with the external MCP server enabled, tools/list returns all 46 tools regardless of which assistant is active, and after activate_btt_assistant the reported visibleToolNames is driven entirely by the assistant's "allow all JavaScript tools" setting - 0 when off, 38-41 when on, with nothing in between. Calls are correctly rejected at the tools/call layer, so enforcement works; skill-based scoping just does not seem to reach it. Happy to send session logs if useful.


Device information:
Type of Mac: MacBook Pro (Mac17,6), Apple M5 Max, 48 GB
macOS version: 26.5
BetterTouchTool version: 6.640 (2026071312), also reproduced on 6.687 alpha (2026073101)

Mh that seems to work fine here. Do other changes in BTT persist for you?

The changes are stored in BTT's standard database, the skills directory is for third party skills created outside of BTT and not used by default.

Do the enabled skills show up here as "Active:"?

So for example the trigger json can look like this:

You're right that it persists - my original report was wrong, sorry for the noise. But there is a real bug here, and I found the repro. It depends on which surface you toggle the skills from.

Does not persist: open the h@llo.ai chat window, use the skills panel inside that window, toggle skills on, restart BetterTouchTool. Every toggle is back to default. (off)

Persists correctly: main BetterTouchTool window, h@llo.ai assistant (from the drop down), than choose the ai assistant → Manage Skills..., toggle, click Done, restart. Selections survive.

So the storage layer is fine and works exactly as you described. Reading the data store directly shows them right where you said, on the assistant's own row:

BTTAIActiveSkills = ["code-assistant","btt-config","background-computer-use","general"]

It looks like the chat window's skills panel only changes the live session and never commits to the row, whereas Manage Skills... in the main window commits on Done. Everything I toggled in the chat window was lost; everything I set via Manage Skills... survived.

My "nothing is written anywhere" claim came from checking with bttcli get_triggers, which does not serialize that field - so I concluded it was never stored. That was my error, not a BTT problem.

To answer your other question: yes, all other BTT changes persist fine here - triggers, actions, and preset edits all survive restarts normally. This was specific to the chat-window skills panel.

The MCP observation in my original post was built on the same bad assumption, so please disregard it for now - I will re-test properly and follow up separately rather than leave a half-verified claim standing.ai