[bug] Settings POST endpoint silently drops keys not in DEFAULT_SETTINGS — non-default prefs lost on save #921

New issue

Closed

opened 2026-06-04 11:32:03 +02:00 by sleepy · 1 comment

sleepy commented

2026-06-04 11:32:03 +02:00

Owner

Bug

When the Settings UI saves via POST /api/auth/settings, the handler at routes/settings_routes.py:60-69 only writes back keys that exist in DEFAULT_SETTINGS:

for key in DEFAULT_SETTINGS:
    if key in body:
        current[key] = body[key]

Keys that were added to settings.json by other code paths (tool manager, email routes, skill routes, etc.) but are NOT in DEFAULT_SETTINGS get silently dropped on every save cycle. This includes:

disabled_tools
email_auto_summarize, email_auto_reply, email_auto_tag, email_auto_spam, email_auto_calendar
email_writing_style
Any future settings added by routes without updating DEFAULT_SETTINGS

Meanwhile, load_settings() does {**DEFAULT_SETTINGS, **saved} which DOES preserve extras in the file. The bug only triggers when the Settings UI does a save — it rewrites the file with only DEFAULT_SETTINGS keys, nuking everything else.

Root Cause

The set_settings POST handler iterates over DEFAULT_SETTINGS keys instead of merging the body into the current settings. It should write back ALL existing keys plus any new ones from the body.

Fix

# Before (broken):
for key in DEFAULT_SETTINGS:
    if key in body:
        current[key] = body[key]

# After (correct):
for key in body:
    current[key] = body[key]

This lets the frontend send partial updates (only changed fields) while preserving all existing keys. Should also validate that unknown keys are allowed (or at least log a warning).

Reproduction

Set email_writing_style via chat tool (manage_settings set email_writing_style=...)
Open Settings UI, change any unrelated setting (e.g. toggle a feature)
Save
email_writing_style is gone from data/settings.json

Impact

This is the likely cause of reported symptoms: teacher model settings, default chat model, and other non-DEFAULT_SETTINGS keys not surviving across restarts — they survive the restart itself (load_settings merges fine), but get wiped the next time the Settings panel saves.

## Bug When the Settings UI saves via `POST /api/auth/settings`, the handler at `routes/settings_routes.py:60-69` only writes back keys that exist in `DEFAULT_SETTINGS`: ```python for key in DEFAULT_SETTINGS: if key in body: current[key] = body[key] ``` Keys that were added to `settings.json` by other code paths (tool manager, email routes, skill routes, etc.) but are NOT in `DEFAULT_SETTINGS` get silently dropped on every save cycle. This includes: - `disabled_tools` - `email_auto_summarize`, `email_auto_reply`, `email_auto_tag`, `email_auto_spam`, `email_auto_calendar` - `email_writing_style` - Any future settings added by routes without updating `DEFAULT_SETTINGS` Meanwhile, `load_settings()` does `{**DEFAULT_SETTINGS, **saved}` which DOES preserve extras in the file. The bug only triggers when the Settings UI does a save — it rewrites the file with only `DEFAULT_SETTINGS` keys, nuking everything else. ## Root Cause The `set_settings` POST handler iterates over `DEFAULT_SETTINGS` keys instead of merging the body into the current settings. It should write back ALL existing keys plus any new ones from the body. ## Fix ```python # Before (broken): for key in DEFAULT_SETTINGS: if key in body: current[key] = body[key] # After (correct): for key in body: current[key] = body[key] ``` This lets the frontend send partial updates (only changed fields) while preserving all existing keys. Should also validate that unknown keys are allowed (or at least log a warning). ## Reproduction 1. Set `email_writing_style` via chat tool (`manage_settings set email_writing_style=...`) 2. Open Settings UI, change any unrelated setting (e.g. toggle a feature) 3. Save 4. `email_writing_style` is gone from `data/settings.json` ## Impact This is the likely cause of reported symptoms: teacher model settings, default chat model, and other non-DEFAULT_SETTINGS keys not surviving across restarts — they survive the restart itself (load_settings merges fine), but get wiped the next time the Settings panel saves.

sleepy referenced this issue

2026-06-04 11:32:57 +02:00

[feature] Custom system prompts — save, switch, and manage multiple prompt templates #923

sleepy referenced this issue

2026-06-04 11:32:57 +02:00

[feature] Rewrite chat_with_model into proper subagent tool with configurable model roles #924

sleepy added the

area:routes

bug

labels

2026-06-04 11:33:44 +02:00

sleepy referenced this issue

2026-06-04 12:13:56 +02:00

[feature] Video Analysis side panel — transcribe + find + summarize (like Deep Research panel) #926

sleepy referenced this issue from a commit

2026-06-04 13:29:36 +02:00

fix: persist all settings keys on POST, not just DEFAULT_SETTINGS (#921)

sleepy referenced this issue from a pull request that will close it,

2026-06-04 13:29:39 +02:00

[settings] Fix POST dropping keys not in DEFAULT_SETTINGS (#921) #928

sleepy referenced this issue from a commit

2026-06-04 13:31:34 +02:00

Merge fix/settings-persistence-921: iterate over body keys instead of DEFAULT_SETTINGS (#928, fixes #921)

sleepy closed this issue

2026-06-04 13:31:49 +02:00

sleepy commented

2026-06-04 13:31:57 +02:00

Author

Owner

Fixed in PR #928 — merged to dev via --no-ff. Root cause: PUT /settings iterated over DEFAULT_SETTINGS keys instead of body keys, so any setting not in the defaults was silently dropped. Fix: iterate body keys, guard with if key in current to prevent arbitrary key injection.

Fixed in PR #928 — merged to dev via --no-ff. Root cause: PUT /settings iterated over DEFAULT_SETTINGS keys instead of body keys, so any setting not in the defaults was silently dropped. Fix: iterate body keys, guard with `if key in current` to prevent arbitrary key injection.