Interactive `/settings` UI for config inspection and edits

[quangdang46]

Interactive /settings UI for config inspection and edits

Summary

Add a /settings overlay (and jcode settings CLI) that surfaces every config key, its current effective value, the scope it came from (default / user / project / env / flag), and lets the user edit it inline. Mirrors pi's /settings.

Reference: pi Settings and docs/settings.md.

Why

• jcode now has many configurable behaviors (provider profiles, compaction reserves, ambient mode, swarm spawn mode, transport preference, telemetry opt-ins, alignment). Today users edit ~/.jcode/config.toml by hand or guess at env-var names.
• An interactive UI prevents the "I changed setting X but it didn't take effect" class of confusion (/settings shows precedence).

Current state in jcode

• src/config.rs and src/config/ hold the config types; no in-TUI overlay for browsing/editing them.
• jcode provider list/current/doctor exist for provider config only.
• Issue Add config default for swarm spawn mode 1jehuang/jcode#211 ("Add config default for swarm spawn mode") and several others would close out faster if there were a UI to expose the knob.

Implementation checklist

1. Reflection of the config types

• Add a derive(SettingsSchema) proc-macro in crates/jcode-config-types (or a hand-written fn schema() -> SettingsSchema) that emits { key, type, default, description, scope_supported } for every config field. Re-using serde field attrs avoids drift.
• Categories: General, Providers, Compaction, Ambient, Swarm, Memory, UI, Telemetry, Network.

2. Effective-value resolver

• For each key, compute (effective_value, source) where source ∈ default | global_config | project_config | env_var | cli_flag | session_override.
• Expose via jcode settings get <key> and jcode settings show --json.

3. TUI overlay

• New overlay in src/tui/settings_ui.rs:
  • Left pane: category tree with search (/ to filter).
  • Right pane: keys in selected category with [value] (source).
  • Enter to edit; r to reset to default; s to switch scope (global ↔ project).
  • ? shows the field description and any examples.
• Editor accepts the field's declared type (string, int, bool, enum). Enum fields use a dropdown.

4. Writes

• On save, write back to the appropriate file (~/.jcode/config.toml for global, .jcode/config.toml for project). Preserve comments + ordering via a TOML edit library (toml_edit).
• Hot-apply where possible (theme, transport preference, compaction thresholds). For fields that need a restart, show a clear toast.

5. CLI parity

• jcode settings list [--category <c>]
• jcode settings get <key>
• jcode settings set <key> <value> [--scope user|project]
• jcode settings reset <key>

Testing

Unit

• Effective-value resolution covers all six sources with priority correctly applied.
• Round-trip read/write preserves unrelated comments in config.toml.

TUI test

• Open /settings, edit ui.alignment to center, save, restart, verify persisted.

Manual

• Set JCODE_TELEMETRY=0 env var; /settings shows the telemetry key with source env_var and dimmed (read-only this session).

Acceptance criteria

• Every documented config key appears in /settings with a description.
• Scope precedence is shown next to each value.
• Writes preserve formatting of existing config files.
• jcode settings set … works in headless mode.

References

• pi: Settings, docs/settings.md.

---

Implementation notes addendum (Devin gap-analysis pass, 2026-05-21)

Verified jcode code paths

• Existing config loader: src/config.rs, src/config/, types in crates/jcode-config-types. Config file lives at ~/.jcode/config.toml (TOML).
• TUI overlay pattern to mirror: src/tui/ui_overlays.rs (help overlay), and the picker pattern in src/tui/account_picker.rs / src/tui/login_picker.rs.
• Slash command registration: append "/settings" to the dispatch in src/tui/app/commands.rs and the help list in src/tui/ui_overlays.rs.

Recommended subscreens (mirror pi)

• General: theme, thinking level default, message-delivery mode (one-at-a-time vs all), transport preference.
• Providers: list configured providers, default, switch.
• Models: scoped-models allowlist, thinking-level per model.
• Sessions: durability, autosave, naming policy.
• Memory & Swarm: jcode-specific toggles.
• Extensions (depends on TypeScript/QuickJS extension runtime for user-defined tools, commands, and hooks #3): list, enable/disable, view capability grants.
• Diagnostics: link into jcode doctor (Add general-purpose jcode doctor diagnostic command #8) output.

Persistence

• Edits write through to ~/.jcode/config.toml (user) or .jcode/config.toml (project). Use atomic-rename to avoid mid-write crashes.
• A small "Open in editor" affordance (uses $VISUAL/$EDITOR) for advanced fields not exposed in the picker.

Cross-references

• TypeScript/QuickJS extension runtime for user-defined tools, commands, and hooks #3, User themes with hot reload #5, Extension capability policy: --extension-policy safe|balanced|permissive + command-level exec mediation #14, Extension trust lifecycle and kill-switch #15 — every customization surface this issue exposes is owned by another issue. Land those first; this issue is the front door.

Reference

• pi-mono: /settings is described under Settings.