feat(bot): INITIAL_SETTINGS_PRESET env var to seed default settings#175
feat(bot): INITIAL_SETTINGS_PRESET env var to seed default settings#175tobyrosen wants to merge 2 commits into
Conversation
The assistant run footer (agent, provider/model, elapsed time) can be toggled at runtime from /settings, but there is no way to preset its default for headless or declarative (.env-based) deployments. Add a HIDE_RUN_FOOTER boolean env var, read via the existing getOptionalBooleanEnvVar helper, that seeds the default for the showAssistantRunFooter setting. It defaults to false (footer shown), so behavior is unchanged unless the variable is set. The runtime /settings toggle still takes precedence and is persisted in settings.json. Document the variable in README and .env.example, and add config and settings-store tests.
|
@tobyrosen thanks for PR. I don't understand the problem, you can hide message footer with /settings command for each install. When I added /settings command, I also wanted to clear .env from some values. If you add something like this, you need to add default values for all runtime settings for consistency. But I'm not sure it's nessesary feature. When you install OpenCode for example you can't set default values for everything in settings |
|
@grinev Fair point on the consistency. I wasn't looking to set defaults for everything in settings, just clear the one churn we actually hit. The issue: I run several bot instances off .env configs (one per session), and reinstalls happen. /settings works, but toggling it per-bot per-reinstall is a manual step we trip over every time. The env var just lets the default ship preset so fresh installs start clean. Two potential options, your call:
Happy to go either way. I should be able to push more today. Thanks! |
|
@tobyrosen I think this feature can exist in that way: |
Replace HIDE_RUN_FOOTER with a single INITIAL_SETTINGS_PRESET env var that accepts a JSON object and seeds any runtime /settings value on first run. Only keys absent from settings.json are affected; settings the user has already changed via /settings are left untouched. Supported keys: ttsMode, compactOutputMode, showThinkingContent, showAssistantRunFooter, responseStreamingMode, sendDiffFileAttachments. Invalid JSON falls back to built-in defaults without crashing. Unknown keys and type mismatches are logged as warnings and skipped. Co-Authored-By: Toby Rosen <46664805+tobyrosen@users.noreply.github.com>
tobyrosen
changed the title
|
@grinev thanks for the design suggestion. I've reworked the PR to implement INITIAL_SETTINGS_PRESET. The var accepts a JSON object and seeds any /settings value at startup; keys already present in settings.json are never touched, so existing users see no change. Invalid JSON, unknown keys, and type mismatches all log a warning and fall back gracefully; no crash. |
2 participants
Description of changes
I run a few instances of this bot from
.envconfigs, and I kept tripping over the run footer on fresh installs. The/settingsmenu from 0.22.0 (#171) handles it nicely at runtime, but there's no way to preset the default, so every new instance starts with the footer on until someone opens/settingsand toggles it. When you deploy several bots from config, that's a manual step per bot per reinstall.Following the review suggestion, this now adds an
INITIAL_SETTINGS_PRESETenv var instead of the original footer-only flag. It takes a JSON object and seeds the initial value for any/settingsoption (ttsMode,compactOutputMode,showThinkingContent,sendDiffFileAttachments,responseStreamingMode,showAssistantRunFooter). A persisted/settingschoice still takes precedence: preset values fill in only where the user hasn't picked anything, so the runtime toggles keep working exactly as they do now.Parsing is defensive: invalid JSON, unknown keys, or wrong value types log a warning and are ignored, so a bad preset never crashes the bot. With the variable unset, nothing changes and existing users see no difference.
The variable is documented in the README and
.env.example, with tests for the parsing and the seeding behavior.Closes issue (optional)
No open issue for this; #134 covered a different footer request and is already closed.
How it was tested
npm run lint,npm run build, andnpm testall pass, including the new tests: preset applied on a fresh install, persistedsettings.jsonvalues never overwritten, invalid JSON / unknown keys / wrong value types ignored with a warning. It's pure config parsing, nothing OS-sensitive.Checklist
<type>(<scope>)?: <description>mainnpm run lint,npm run build, andnpm test