#5443·OctoPrint

Settings dialog Save silently sends only a fragment of the settings tree; widespread 403s on background API polling

Author: SLSettlesCreated Aug 9, 2026Updated Aug 24, 2026
Labelsneeds informationunreproducedtriage

The problem

Title: Settings dialog Save silently sends only a fragment of the settings tree; widespread 403s on background API polling (reproduces in Safe Mode)

OctoPrint version: 1.11.8 OS: OctoPi 1.1.0 on Raspberry Pi 3 Model B Plus, Python 3.11.2 Browser: Chrome (also reproduced via automated Chromium/Playwright) Printer: Ender 3 V2 SE (not relevant to reproduction — also reproduced against Virtual Printer)

Summary: Clicking Save in the full Settings dialog sends a POST to /api/settings containing only a small fragment of the actual settings tree (e.g. just {"temperature": {...}}) instead of the complete gathered payload. Plugin settings changes made in the same dialog session are silently dropped — no error shown to the user, HTTP 200 returned, but the changed values never reach config.yaml. Separately, background polling requests (GET /api/printer, GET /api/job, GET /api/plugin/) intermittently/persistently return 403 even with a valid authenticated session.

This reproduces in Safe Mode with zero third-party plugins running. Launched via octoprint serve --safe, confirmed via startup log ("Starting in SAFE MODE. Third party plugins will be disabled!"), the 403 pattern still occurs — including on bundled core plugin endpoints such as /api/plugin/tracking. This rules out any plugin (mine or otherwise) as the cause and points at core session/auth handling.

Steps to reproduce:

Install any plugin implementing SettingsPlugin with get_template_configs() returning a type: settings entry (automatic binding, custom_bindings not set) — or skip this entirely and reproduce the 403 portion alone in Safe Mode, see below Open Settings → the plugin's section, change a value Click the dialog's single footer Save button Inspect the Network tab request to /api/settings — payload does not include the plugins key at all, or is otherwise truncated Confirm via config.yaml (Settings → Backup & Restore) that the changed value never persisted

To reproduce the 403 portion independent of any plugin:

Start OctoPrint with --safe (disables all third-party plugins) Load the UI in a browser with a normal authenticated session Observe repeated 403 Forbidden on GET /api/printer, GET /api/job, GET /api/plugin/tracking, and similar polling endpoints in the Network tab

Expected: Save gathers and sends the complete settings tree, including all plugin sections; changed value persists. Authenticated background polling succeeds consistently.

Actual: Only a small, seemingly arbitrary fragment is sent on Save; change is silently lost. Background polling returns 403 repeatedly even from an authenticated session, in both normal and safe mode.

Additional notes:

Confirmed via Request call stack in Chrome DevTools that the Save request does go through the legitimate SettingsViewModel.self.saveData → OctoPrintSettingsClient.save path, not a rogue plugin intercepting the save. Reproduced on a from-scratch OctoPrint instance with no third-party plugins besides the one being tested (prior to the Safe Mode test above), ruling out plugin-to-plugin interference as well. A hand-built POST /api/settings (via curl) with the complete correct payload succeeds and persists correctly, confirming the backend correctly processes complete payloads — the failure is specifically client-side, in gathering the full payload before send. This general symptom shape (broad 403s tied to API-key/CSRF handling) closely resembles two previously-fixed issues: the 1.11.0rc1→rc2 regression (#5098/#5100) and the 1.11.2 fix (#5156, "Fix 403 errors triggered by access_validation_factory"). Possibly a related area resurfacing, though this instance is already past both fixes. Logs, a HAR capture, and Safe Mode startup log available on request.

Did the issue persist even in safe mode?

Yes, it did persist

If you could not test in safe mode, please state why ("currently printing" is NOT an excuse!)

Mac mini M4 26.5.1 running Chrome, OctoPi 1.1.0 on Raspberry Pi 3 Model B Plus, Python 3.11.2 deets in report.

Version of OctoPrint

1.11.8

Operating system running OctoPrint

OctoPrint 1.11.8 Python 3.11.2 OctoPi* 1.1.0 (build 2025.09.09.113029 on Pi 3 B Plus

Browser and version of browser, operating system running browser

Chrome 151.0.7922.76 Mac mini M4 26.5.1

Printer model & used firmware incl. version

Ender-3 V2 SE

Systeminfo Bundle

octoprint-systeminfo-20260809215815.zip[^bundle1] config.yaml.zip

Checklist of files to include below

  • Contents of the JavaScript browser console (always include in cases of issues with the user interface)
  • Screenshots and/or videos showing the problem (always include in case of issues with the user interface)
  • GCODE file with which to reproduce (always include in case of issues with GCODE analysis or printing behaviour)

Additional information & file uploads

No response

[^bundle1]: octoprint-systeminfo-20260809215815.zip (bundleviewer) (download) OctoPrint: 1.11.8 Python: 3.11.2 OS: Linux-6.6.51+rpt-rpi-v7-armv7l-with-glibc2.36 RPi: Raspberry Pi 3 Model B Plus Rev 1.3 OctoPi: 1.1.0 (build 2025.09.09.113029) Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36