* feat: add optional tool approval mode
Admin-configurable tool_approval_mode setting (ask/auto) for the
post-external-context tool approval gate.
- ask (default): existing approval flow, gate stays on
- auto: bypasses the approval gate for all runs - same effect as
ODYSSEUS_TOOL_APPROVAL_GATE=0. Documented honestly in the settings
row copy and in THREAT_MODEL.md, per review on #6304.
- value validated server-side ({ask, auto}, anything else -> 400)
- no new env var: the setting wires to the existing gate control
- tests: setting validation + _tool_approval_gate_bypassed behavior
* feat: surface deployment gate state on Tool approval row
Follow-up to StressTestor's re-review: when ODYSSEUS_TOOL_APPROVAL_GATE is
set to a falsy value, the Tool approval row still read 'Always ask' even though
the gate was off, misleading admins the other way.
GET /api/auth/settings now returns tool_approval_gate_env_disabled (derived
from TOOL_APPROVAL_GATE_ENABLED) for admins, and the settings row renders a
red notice naming the env var and explaining that the gate is off for every
run regardless of the stored setting. Non-admin/scrubbed responses do not
expose the deployment state. Test covers both env values and the scrub path.
* refactor: rename tool approval mode auto to off
The gate-off value is now "off" ("Off (YOLO)" in the UI) so the auto-approve name stays available for the future judged mode.
---------
Co-authored-by: Matej <matej@local>
static/js/settings.js was 5,721 lines behind a four-name public surface.
static/js/settings/ already existed with dom, registry, search, sidebar,
navigation and lifecycle, so this continues that package rather than
inventing a layout.
Moved verbatim, 407 lines:
settings/speech.js initTtsSettings, initSttSettings
settings/writingStyle.js initDocumentWritingStyle
settings/imageModels.js initImageSettings
settings/agent.js initAgentSettings
settings/api.js postSettings, lifted from _postSettings
These five were chosen because their only dependencies outside themselves
were el/byId, _postSettings and sortModelIds. Panels with wider reach stay
put: initEmailAccountsSettings, for instance, pulls a 64-declaration closure
covering most of the file, and splitting that is a design change rather than
a move.
settings.js keeps its public surface exactly: open, close,
refreshAiModelEndpoints and the default export, verified in a browser.
Three test updates the move required:
- tests/helpers/test_settings_shell_coordinator.mjs allowlists the real
modules the coordinator may import, and rejected the new ones. That guard
working is the reason to trust the rest of this diff.
- two source-introspection tests read settings.js for behaviour that now
lives in a panel module. They read the whole settings surface now, so the
next extraction does not break them again.
