Every setting should be expressible in a config file

[colonelpanic8]

TL;DR: Most T3 Code settings live in JSON files that can be kept in dotfiles or generated by Nix. Some exist only as CLI flags, env vars, or browser localStorage, and some config files also hold app state. Would you accept closing those gaps?

Settings without a file form

• Server daemon options. Port, host, mode, Tailscale serve, log level, OTLP export, and tracing are only flags or T3CODE_* env vars (apps/server/src/cli/config.ts). settings.json has no equivalent, so a service setup keeps them in a unit file or wrapper script, apart from everything else.
• Web client settings. The web client keeps its settings in localStorage["t3code:client-settings:v1"], and the theme choice and typography in other t3code:* keys. They can't be provided from a file, and every new browser or hostname starts from defaults (Store appearance and behavior settings on the server that serves the web app #16899).

Config files that also hold state

The app rewrites these during normal use, so they can't be generated or kept read-only:

• desktop-settings.json stores mainWindowBounds and mainWindowMaximized next to updateChannel and the WSL options.
• Server settings.json stores markers the app writes for itself: projectSettingsFolded (legacy project settings were folded in), deviceOnboardingCompleted (the environment's device setup ran), and defaultThemeSetAt (a theme generation stamp).

#19595 shows the practical cost: moving the desktop window rewrites a desktop-settings.json kept in dotfiles.

A file form is also what makes shared vs machine-local settings (#19594) and managed overrides (#16883 / #16931) possible. A setting with no file can't be layered or enforced.

Questions

1. Would you accept reading daemon options from a server config file, with flags and env vars still taking precedence?
2. For web client settings, is a file the server provides (as Store appearance and behavior settings on the server that serves the web app #16899 suggests) the direction you want?
3. Would you accept moving window state and these app-written markers out of the config files and into the data directory, keeping their current owners?

Prior art

• Codex keeps its options in config.toml, with -c key=value overriding per run.
• Claude Code keeps its options in settings.json files, with CLI flags overriding per session.

Related

• Separately configurable locations for server config, server data, and client files #19591: separately configurable locations for server config, server data, and client files
• A rule for which settings the client owns and which the environment owns #19593: which settings the client owns and which the environment owns
• Keep dotfile-managed settings separate from machine-local changes #19594: keeping dotfile-managed settings separate from machine-local changes
• Store appearance and behavior settings on the server that serves the web app #16899: storing web client settings on the server that serves the web app
• [Feature]: Provide proper files to move the configuration between environments #6802: configuration files that can live in a dotfiles repo
• [Feature] Enterprise managed configuration overrides #16883 / feat(server,web,desktop): enforce organization-managed settings #16931: managed configuration overrides

[colonelpanic8]

A proposed first step is on my fork, not opened here: colonelpanic8#6. It adds an optional server.json (default <configDir>/server.json, or --server-config-file / T3CODE_SERVER_CONFIG_FILE) for the daemon options that are currently only flags or env vars. Precedence is flag > env > desktop bootstrap > file > default, and the file deliberately has no location keys. It stacks on colonelpanic8#4. Happy to open it here if you want it.