Function update_user_setting 

pub fn update_user_setting(
    user_dir: &Path,
    key: &str,
    value: Value,
) -> Result<PathBuf, String>

Write key = value into the user settings file, preserving every other key.

This is the write half of the settings layer: /model persists the model the same way both reference harnesses do — into the user-global file (Claude Code’s updateSettingsForSource('userSettings', { model }); grok’s [models].default in ~/.grok/config.toml). Neither has a project-scoped model, and neither needs one: a running session holds its model in memory, so the file only decides what the next session starts with.

The write is atomic. The new contents go to a temp file in the same directory — same filesystem, so the rename cannot fail with EXDEV — are flushed to disk, and only then renamed over the target. rename(2) is atomic, so a crash, a full disk or two processes writing at once can leave the file as the old contents or the new, never a truncated mixture. A half-written settings.json would be worse than no write at all: the next run would fall back to defaults with no way to tell why.

Errors

The path could not be resolved, created, written, or renamed. The existing file is untouched in every failure case.