Skip to content
coding agent tips

settings and memory

last updated

where do the settings go?

Grok Build loads configuration from your machine and the current project. Grok Bot uses profiles and account settings for persistent agents. start by identifying which one you are changing.

the settings guide limits project configuration to those three jobs. model choices and interface preferences belong in your user configuration. GROK_HOME can change the location of that personal directory. managed configuration and requirements can also constrain the effective settings on an organization managed machine.

which settings did it load?

for a session where you want to review tool approvals, the documented user setting is:

# ~/.grok/config.toml
[ui]
permission_mode = "ask"

a repository can add a targeted command rule:

# .grok/config.toml
[permission]
rules = [
  { action = "deny", tool = "bash", pattern = "git push *" }
]

then inspect discovery from that repository:

grok --version
grok inspect

check the listed user configuration, project configuration, instructions, and permission sources. the rule above demonstrates command matching. publishing can happen through other commands or tools, so a repository policy needs to cover the actual available paths. the permission documentation explains how deny, ask, and allow rules interact.

on September 7, 2026, an agent run for this guide tested configuration discovery with Grok Build 0.2.22 on macOS, using a disposable project and a separate GROK_HOME. grok inspect found the project rule and both configuration files. it also discovered existing compatibility settings from the host. this was a discovery test; enforcement and model behavior were outside its scope.

that extra discovery matters when a fresh directory behaves like an old setup. Grok can also load Claude and Cursor configuration through compatibility scanners. inspect the loaded sources before assuming a setting came from .grok/. the settings reference lists those scanners and their controls.

what can it actually access?

ask, auto, and always approve control tool permission decisions. auto uses a classifier where the feature is available; deny rules and hooks still apply. a sandbox limits filesystem and network access when active. its profile and enforcement determine what an approved command can reach. inspect both controls before unattended work.

how should i set up a Bot?

Grok Bot profiles hold a name, description, avatar, and ongoing instructions. a useful role might be “collect documentation changes for these three libraries.” put the specific libraries, date range, and expected output in the conversation for this run.

for example:

check these three official changelogs since last friday. save a summary with links and dates. flag anything that could change our setup. return the file for review before sending it anywhere.

keep the Bot’s identity separate from its access. names and avatars help you recognize the worker; account permissions and connected sessions determine what it can do. hiding a Bot keeps its history and can leave ongoing work running. use the actual work controls when you intend to stop a task.

media preview

by