Repository navigation
[Bug]: Every settings save fails with "write-file failed" when the Source Control writing style mixes default and custom values (regression from #21665) #22201
Description
Summary
Since #21665 ("accept legacy writing styles when reading settings"), every settings save fails when some sourceControlWritingStyle fields are at their defaults and others aren't. One example is mode Conventional commits with empty custom instructions. The UI says T3 can't write the settings file, but the real cause is a schema encode error:
ServerSettingsError: Server settings write-file failed at ~/.t3/userdata/settings.json.
at ws.rpc.server.updateSettings
at server.runServerCommand {
[cause]: SchemaError: Missing key
at ["sourceControlWritingStyle"]["customInstructions"]
}
server.updateSettings rewrites the whole file, so the failure isn't limited to Source Control settings. Project settings, environment preferences, and the t3_environment_preferences_update MCP tool all fail too. The file on disk stays intact.
Environment
- Linux (WSL2), server built from
mainat069e63b11758(2026-10-20) - Last working build:
1451e7cb2303(2026-10-19)
Steps to reproduce
- Open Settings → Source Control and set the writing style to Conventional commits. Leave custom instructions empty and keep change request templates on.
- If this was saved on an older build,
settings.jsonalready contains"sourceControlWritingStyle": { "mode": "conventional_commits" }.
- If this was saved on an older build,
- Change any other setting, for example a project setting.
Expected: the setting saves.
Actual: the save fails with the error above.
Cause
writeSettingsAtomically (apps/server/src/serverSettings.ts) runs stripDefaultServerSettings before encodeServerSettingsJson. sourceControlWritingStyle isn't in ATOMIC_SETTINGS_KEYS, so its default sub-fields are stripped and the encoder receives { mode: "conventional_commits" }.
#21665 changed the field to Union([TrimmedString, SourceControlWritingStyleSettings]).pipe(decodeTo(toType(SourceControlWritingStyleSettings), …)). On encode, the value is first checked against toType(...). That type requires all three keys, because withDecodingDefault only applies on decode. The partial object is rejected with Missing key. Before #21665, the plain struct encoded the same partial object without errors.
The tests in #21665 cover decoding legacy strings. None of them sends a partial value through the server's write path.
Workaround
Set the writing style back to Repo conventions. With every field at its default, the whole object is stripped and never reaches the encoder.
Fix
Proposed in #22203.
Activity
MaximilianMauroner commentedon Oct 20, 2026
🤖 Comment made by GPT-6 acting on behalf of @MaximilianMauroner.
Confirmed in the packaged nightly
0.1.1-nightly.20261020.3386, with additional platform evidence:The macOS UI reproduced the error when disabling a configured Codex provider under Settings > Providers. The switch stayed on. The Ubuntu server logs show the same schema failure. Both settings files contained:
The relevant log cause was identical on both machines:
The files had the expected owner and write permissions. An isolated call to the installed module's serializer reproduced this exact schema error without a filesystem write.
As an additional diagnostic, keeping
sourceControlWritingStylewhole through the existingATOMIC_SETTINGS_KEYSset passed encode/decode round trips for Conventional Commits with default fields, repository conventions, custom instructions, and disabled change-request templates. Each case compared the complete decoded settings before and after the round trip, including the disabled provider flag. This was an isolated alternative probe, not a test of #22203. No code patch was installed.A temporary workaround also preserved the existing writing style: back up
settings.json, then edit only the provider'senabledflag on disk. The running servers loaded the changes, and T3 showed the provider disabled on both environments without a restart. This sets the requested provider state, but general UI settings saves still fail.PrpCena commentedon Oct 21, 2026
Confirming this still reproduces on the last build that predates the fix, so the fix can be bisected if needed.
Pre-fix build that reproduces:
0.1.1-nightly.20261020.3411(d36b7da2485b, released 2026-10-20T10:44:44Z) — roughly 6h before #22203 was merged (d652490, 2026-10-20T17:09:05Z). The fix therefore does not reach that nightly.Reproduced there on macOS 27.0.1 / arm64, T3 desktop, with the OpenCode provider as the only enabled instance. The failing file on that machine held a writing style where one field was non-default and the others were default:
which surfaces as the same two failures reported here:
and, with
modeset andcustomInstructionsleft at its default:Both variants were reproduced against the installed bundle's own schema, without touching the filesystem, and the same partial object is what
stripDefaultServerSettingsproduces from the decoded value.One extra data point that may be useful: on that machine the failure was not limited to a deliberate writing-style change. The
settings.jsonwas already holding the partial object from an earlier build, and from then on every settings write failed — Settings, project settings, and thet3_environment_preferences_updateMCP tool — becauseserver.updateSettingsrewrites the whole file. A file that was valid on an older build could not be written again by a newer one, with no way to recover from the UI.The fix in #22203 is present in
v0.1.1and in0.1.2-nightly.20261021.3457and later.