Grok Joins the Party

TL;DR

I now have three AI coding assistants: Claude Code, Codex and Grok Build.

I can give one a job like “fix this broken page.” It can read the project, change the files and run checks. I can then ask another to inspect the change and look for mistakes.

Grok is the new arrival. I’ve set it to use Grok 4.6 at its highest thinking setting, and to run commands and edit files without asking me to approve every step.

That gives me another assistant to do the work and another opinion to check it.

A third seat at the table

Claude Code and Codex were already part of my daily setup. Now I have SuperGrok Heavy, and I’m bringing Grok Build into the same working environment.

The names need separating before this gets technical.

SuperGrok Heavy is the subscription I pay for. Grok Build is the program I use to work on software. Grok 4.6 is the AI model running inside it.

Think of Build as the hands: it opens files, edits them and runs commands. The model decides what to do with those hands. That is why a coding assistant can take a task further than a chat window full of suggestions. Grok Build overview.

Here is what I’m paying each month for the three subscriptions:

Those are my subscription amounts, not a quote for every region, billing arrangement or extra service. They also do not buy unlimited coding. Grok Build draws from my plan’s weekly allowance, alongside chat and other Grok features; Claude and Codex have their own usage limits. Grok usage FAQ, Claude plans, ChatGPT plans.

I want a third system I can give a real task, or ask to challenge work from the other two. For example: one assistant changes a function, another checks the tests, and a third looks for a case they missed. They can still all be wrong. Passing the actual tests and reviewing the actual changes remain part of the job.

That is the reason for adding Grok. Whether the extra $300 earns its place will depend on the work it produces.

What “full power” means here

My existing choices are Claude Fable 5.1 at max and GPT-6 Astra at ultra. Grok’s equivalent choice in this setup is Grok 4.6 at xhigh.

“Reasoning effort” is the setting that asks the model to spend more effort working through a problem. The names differ between companies; max, ultra and xhigh are not a shared measurement scale.

For Grok 4.6, the advertised choices are low, medium, high and xhigh. The default is high. I chose xhigh, the highest supported choice, accepting that responses may take longer. The command-line parser also accepts max, but for Grok 4.6 that does not create a level above xhigh. Grok reasoning settings.

Grok 4.6 accepts text and images and has a 500,000-token context window. Tokens are the small pieces of information a model processes; the context window limits how much it can hold in a request. A larger window can fit more project material, but the right files still have to be selected. Grok 4.6 model details.

This article records my configuration and checks on September 6, 2026. It does not claim that selecting the highest setting has already made Grok better than Claude or Codex on my work.

The settings live in one maintained place

I keep these settings in a personal collection called my dotfiles. Git tracks their changes so I can restore an older version or reuse the setup on another machine. The files Grok reads are links to those maintained copies.

The main link is:

~/.grok/config.toml
    → ~/dotfiles/home/.grok/config.toml

The same arrangement covers the Grok rules, helper roles, launch wrapper and macOS background jobs. The installer recreates the links. Personal assistant configuration stays outside client repositories.

Here is the core model configuration, as an excerpt rather than a replacement for the whole file:

[models]
default = "grok-4.6"
default_reasoning_effort = "xhigh"
web_search = "grok-4.6"
session_summary = "grok-4.6"
image_description = "grok-4.6"
prompt_suggestion = "grok-4.6"
inference_idle_timeout_secs = 3600
max_retries = 8
subagent_rate_limit_max_attempts = 8
stream_tool_calls = true

[model."grok-4.6"]
reasoning_effort = "xhigh"

The smaller background jobs matter too. Summarising a session or describing an image can use a separate model selection. Changing the main chat model alone does not necessarily change them. I explicitly assigned those jobs to Grok 4.6. I also set ui.fork_secondary_model = "grok-4.6" for the secondary model used when starting a fork — a new branch of a conversation.

There is a small configuration trap in [model."grok-4.6"]: the model identifier inside the square brackets needs quotes. In TOML, the settings format, an unquoted dot means another level of nesting. [model.grok-4.6] therefore creates the wrong structure. The setup corrected that and checked the parsed model keys.

I left the maximum output-token setting unset. There is no extra output cap in this profile just to make a long answer cheaper. The one-hour idle timeout and retry settings give long requests room to finish or recover; they do not guarantee completion. Build settings reference.

Typing grok should be enough

A setting that works only when I remember a special command is easy to lose.

My normal entry point is simply:

grok

That command first reaches a small script at ~/.local/bin/grok. This is a wrapper: it adds my defaults and then starts the real program at ~/.grok/bin/grok.

For ordinary launches, it supplies:

--always-approve --effort xhigh -m grok-4.6

It handles three ways of starting work:

# Work interactively in the terminal
grok

# Give it one task from a script
grok -p "Inspect the recent change and explain any bugs."

# Let a compatible editor communicate with it
grok agent stdio

The second form is called headless: no interactive chat screen is needed. The third uses the Agent Client Protocol, or ACP, to connect an editor to the agent. Headless and scripting documentation.

Maintenance commands such as grok inspect, grok models, grok update and grok --version pass through without the extra flags. If I explicitly choose a model, effort or permission mode, the wrapper respects that choice. GROK_WRAPPER_DISABLE=1 skips its injected defaults; GROK_REAL_BIN=/bin/echo lets me print the arguments for a check without starting a model request.

The shell’s PATH is the ordered list of places it searches for programs. I put ~/.local/bin back at the front after the Grok installer adds its own directory. Otherwise, the installer’s binary could be found before my wrapper.

There is no extra gk alias. It was added during setup and then removed: grok already does the job, and the shell’s Git plugin already uses gk for something else.

Terminal settings also need to reach the editor

Programs started from the desktop do not necessarily inherit the settings from an open terminal.

The setup therefore covers both shell startup files, ~/.zshrc and ~/.zprofile, plus a small macOS LaunchAgent. A LaunchAgent is a background job macOS runs for my user account. This one supplies the same environment defaults to desktop applications opened afterward, such as my editor.

These switches enable memory, web reading, helper agents, workflows and code-navigation tools. They also keep the sandbox off and disable several prompts, which I explain below:

export GROK_MEMORY=1
export GROK_WEB_FETCH=1
export GROK_SUBAGENTS=1
export GROK_WORKFLOWS=1
export GROK_ASK_USER_QUESTION=0
export GROK_SANDBOX=off
export GROK_FOLDER_TRUST=0
export GROK_DEFAULT_SELECTED_PERMISSION=always_allow_all_sessions
export GROK_LSP_TOOLS=1

Already-running applications may need restarting to receive changed environment settings. A program that directly starts the real binary bypasses the wrapper’s flags, although Grok’s user configuration still applies.

I deliberately leave GROK_DEFAULT_MODEL unset so an explicit model switch remains possible. The instruction to avoid silent downgrades lives in my Grok rules file; leaving an environment variable unset is not a mechanism that proves no fallback can occur.

The helpers need their own settings

An assistant can delegate a narrow job to another session: search some files, review a change, write tests. These child sessions are called subagents.

Setting the main session to maximum effort was only part of the work. Some bundled helpers came with lower settings of their own: exploration at medium, quick search at low, and several others at high.

I added user-level role files under ~/.grok/roles/ for nine jobs: exploration, planning, quick search, implementation, review, security audit, test writing, design-document writing and design-document review. Each now explicitly selects Grok 4.6 at xhigh. The three search/planning roles retain their read-only tool boundaries.

The model routing is explicit too:

[subagents]
enabled = true
max_concurrent = 32
sampling_limit = 32
limit_behavior = "queue"

[subagents.models]
explore = "grok-4.6"
plan = "grok-4.6"
general-purpose = "grok-4.6"

Thirty-two is the configured ceiling, not a claim that I am running 32 useful workers or getting 32 times the output. max_concurrent limits child sessions; sampling_limit limits their simultaneous model calls within one process. Extra work queues when the limit is reached. These are Build’s child sessions, not a description of what the Heavy subscription does internally. Build subagents.

A persona is a reusable description of how a helper should work. The researcher persona already had an explicit Grok 4.6/xhigh override in the main configuration. The follow-up audit extended explicit defaults to all seven personas: researcher stays in the main file, with six others in native user persona files. Their instructions and tool capabilities are preserved.

These settings establish defaults. Explicit launch or delegation choices can override them. Checking a configuration file is also different from observing every request sent to the model.

YOLO, in actual settings

I want routine tool calls to run without an approval click. The relevant configuration is:

[ui]
permission_mode = "always-approve"
yolo = true

[permission]
allow = ["*"]

[sandbox]
profile = "off"
auto_allow_bash = true

[features]
remember_mode = false
ask_user_question = false

permission_mode is the current setting; yolo is the older compatible name. I set both consistently. remember_mode = false prevents an in-session mode change from becoming the remembered default for later sessions. The structured question tool is disabled as part of the same preference for uninterrupted execution.

Two different decisions are involved. Automatic approval removes normal permission prompts. Turning the sandbox off removes Grok’s extra operating-system restrictions on the tools it launches. A sandbox is the boundary that would otherwise limit what those tools can access. Grok’s documentation lists it as off by default; I explicitly record profile = "off" rather than relying on that default. Build permissions, Build sandbox.

I also disabled the prompt that asks whether to trust a project folder, allowed Grok to fetch pages from services running on my own computer, and let its file tools read files that Git leaves out of version history. Leaving a file out of Git therefore does not hide it from Grok.

This is my machine configuration. An incorrect command can change real files without waiting for me to click yes. Fetched pages and tool output can also contain misleading instructions. With these settings, the assistant can act on those instructions and read ignored files such as .env files that may contain credentials. Explicit deny rules, blocking scripts called hooks, and administrative restrictions can still apply; “YOLO” does not mean every rule disappears. Plan review can still require approval, and the model’s product policies still apply.

One operational detail deserves particular attention: my setting allows child agents to continue when the parent turn is cancelled. Cancelling the visible turn is therefore not proof that all its children have stopped.

Reusing Claude’s setup without pretending they are identical

Grok can discover instructions, skills, plugins, agents and external-tool connections from an existing Claude Code setup. That removes a lot of repetitive installation work. Skills and compatibility documentation.

A skill is a reusable set of instructions for a particular job. An MCP connection lets the assistant use tools supplied by another program or service. A hook runs a script when a particular event happens, such as a tool call.

My native inspection reported the shared Claude instruction file, Grok’s own ~/.grok/rules/max-power.md overlay, and the permission rules in ~/.claude/settings.json. Those imported permission rules can affect what Grok is allowed to do. The overlay translates the model and effort requirements into Grok’s names and asks it not to silently choose a weaker model.

Claude skills, rules, agents, MCP connections and sessions are enabled for discovery. Imported Claude hooks are deliberately disabled. Those scripts were written for another runtime; discovering them is not enough to establish that running them as Grok is correct. Cursor hook compatibility remains at its shipped default of enabled, but native inspection found no Cursor hooks in the home or article-repository contexts I checked.

There is another subtle limit in the official documentation: Grok accepts model and effort fields in a skill’s metadata but does not apply them. The skill’s allowed-tools field does not enforce tool permissions either. That is why I checked Grok’s native settings and helper definitions instead of assuming that imported files preserved every behaviour.

This gets Grok access to reusable working material. It does not establish that all three assistants now have identical hook enforcement, usage accounting or automation integration.

The rest of the working profile

I kept the useful capabilities enabled. Here are the other settings that materially affect how the assistant works:

A worktree is a separate checkout of a Git repository. These convenience settings do not automatically isolate parallel edits into separate checkouts. Task ownership still needs managing.

Enabled means configured on. It does not mean I exercised every media tool, connection or long-running workflow during this audit. The featured image for this article was made through my existing GPT Image 2 pipeline.

Updates should not depend on remembering to open a chat

The installed command-line program was Grok 1.0.13, matching the latest entry in the official changelog when checked. Grok Build changelog.

The CLI uses my Grok account login; its native model listing reported a grok.com session.

Its configuration selects the stable release channel and automatic updates:

[cli]
auto_update = true
channel = "stable"

I also have a separate macOS job that checks at login and every hour. It runs the maintained grok-auto-update.sh script, records results and reports failures in a log and a macOS notification.

That provides an update path independent of an interactive launch. Built-in startup checks depend on the launch mode and installation conditions; I do not want to rely on every editor or scripted run taking the same path.

Both background jobs were loaded. The hourly updater reported a successful last exit, and its stored checks said the installed version was already current. That verifies the schedule and successful checks, not a witnessed upgrade from an older release.

What the audit caught

The initial setup alone took five commits; the follow-up fixes added more. Reading the notes alone was not enough; I checked the live links, parsed settings, command resolution and remote Git state.

Several details had already been corrected during installation: the quoted TOML model key, the separate image-description model, lower-effort helper roles, the shell path order and the unnecessary alias. The older configuration already contained always-approve, alongside yolo = false; this was a cleanup into consistent, durable defaults, not a claim that every permissive setting was newly invented.

The follow-up audit also found issues worth fixing before calling this finished:

• Helper defaults: five personas still declared high effort, and another relied on inheritance. A matching role could already override those values, so this was a configuration gap, not proof of weaker past runs. All nine maintained roles and all seven personas now explicitly select Grok 4.6/xhigh.
• Prompt parsing: -- marks where command options end and prompt text begins. The wrapper could mistake option-like words after that marker for real model or effort choices. It now keeps those two parts separate.
• Explicit overrides: the compact model option, -mMODEL, could receive a duplicate model flag. Supplying all the defaults explicitly could also crash the wrapper under macOS’s older Bash because its extra-arguments array was empty. Both cases are corrected.
• Update confirmation: the updater could report an upgrade after the update command returned success, even if the old version remained installed. It now reads the installed version again and checks it before reporting success.

The regression checks use temporary directories and fake executables. They reproduce command parsing and update outcomes without spending a model request or modifying the real installation.

The checks included TOML and macOS job-file parsing, shell syntax, native grok models and grok inspect, and wrapper probes that printed arguments without sending a model request. The live Grok files were checked against their maintained sources, and the remote repository was checked independently of the setup notes. The setup and repairs are committed and pushed. I also saved the remaining Codex configuration in a separate commit. A final check found no uncommitted changes in that configuration repository, with its local and remote commits matching.

These are the basic read-only commands for inspecting the installed setup:

command -v grok
grok --version
grok models
grok inspect

The CLI reference describes these inspection commands.

Grok remembers that I acknowledged its privacy banner, but its own inspection tool warns that it does not recognise that saved setting. I kept the warning in the audit rather than claiming a completely clean result. It is separate from the model and permission settings.

Now it has to earn the seat

The setup gives me a repeatable way to start a third coding assistant with the model, effort and permissions I intended. The next question is much more practical: does it finish useful work, find mistakes, and leave changes I want to keep?

I will judge that from completed tasks: what passed, what needed correction, how long it took, and how much of the subscription it used. Buying the plan and passing configuration checks do not answer those questions.

For now: Claude Code, Codex, Grok Build. Three assistants available. Real work waiting.

Welcome to the party, Grok.

Related reading

• Grok Build — my original launch assessment; this article records the newer model and my actual setup.
• Astra × Fable: Full Power, Less Waste — how I configured the other two assistants.
• Your Agents Eat Your Subscription — why automated work still has usage costs.
• I Love Trios 😈 — three assistants on one desk: same notes, same rules, same review path.