Configuration

tCode's settings are saved locally and persist across sessions, so a preference you set once, a theme, an effort level, an auto-approved tool, stays set the next time you open a terminal, rather than resetting every time.

Thinking effort

/effort low, /effort medium, or /effort high trades response depth against speed, and is remembered as your default going forward.

Code theme

/theme on its own lists every available syntax highlighting style along with a live preview of a short code sample in that style, so you can see the colors before committing to one.

Auto-approve

/config auto-approve <tool> on|off turns off the permission prompt for one specific tool going forward, across every future session, not just the current one.

Model

/model lists every tAI model available on your account and lets you switch which one the current session uses.

Where settings actually live

All of this lives in tCode's own configuration directory, alongside your saved login session; see Security for exactly what is stored there and how it is protected.

Checking your current settings

/config on its own prints a summary of what is currently set, useful as a quick check before starting a session on a machine you have not used tCode on in a while, or after switching between a few different projects with different auto-approve preferences.

Stored per machine, not per account

Settings are stored per machine, not per tAI account: signing in to the same account on a second machine starts that machine with tCode's own defaults, not whatever was configured on the first one, aside from the code theme, which is the one setting synced through your account specifically because it is also used by the tAI web app.

Why there is no single reset-everything command

There is no single command that resets every setting back to its defaults at once.

Settings versus the permission boundaries themselves

None of these settings affect what tCode is allowed to do on your behalf without your knowledge; they change how it behaves within the boundaries already described in Permissions and safety, not the boundaries themselves.