Grok Build

Grok Build runs as the developer's own OS user with no narrower identity of its own. Every shell command and every MCP server it launches inherits the full process environment by default, so cloud keys, tokens and API keys in your shell are available to anything the agent runs. An environment-scrubbing policy exists but ships as a no-op. The only thing standing between a hijacked agent and your ambient credentials is the per-call approval prompt.

The default interactive mode asks before every shell command, file edit, MCP call, sub-agent launch and non-allowlisted web fetch, and the prompt shows the exact call. Commands are parsed with a real bash parser, chained segments are checked one by one, deny rules win even over always-approve, and edits to hook, settings and shell-startup files always re-prompt. The weak spots are around the gate: the first prompt of a session preselects 'Yes, and don't ask again for anything (always-approve mode)', which is saved for every future session; a trusted repo's Claude-style settings can switch on bypass mode; and a sub-agent defined with bypassPermissions runs its own calls unprompted. There is no undo for files changed by approved commands.

The core tool is a general-purpose shell, and the read, write and edit tools accept any path on the machine; only a short list of sensitive edit targets forces a prompt. Web fetch is the exception: it blocks private and metadata addresses and handles redirects itself. Every tool, including shell, write and web access, is enabled by default and can only be removed one by one with flags.

Out of the box, shell commands, test runners, hooks and MCP servers run directly on your machine as your user, with your home directory, credentials and network. Grok ships a capable optional OS sandbox (Landlock or bubblewrap on Linux, Seatbelt on macOS) that confines the whole process and its children and refuses to start when a profile that needs protection can't be enforced, but it's off unless you pass --sandbox or set it in config. Child-network blocking in the strict profiles works on Linux only.

Grok reads web pages, search results, repository files and MCP tool output, and treats it all as ordinary context with no provenance tracking. What limits a hijack is the default approval gate: shell commands, edits, MCP calls and fetches to non-allowlisted hosts all need a click, so exfiltration and destructive actions are not unattended in the default mode. But file reads anywhere on disk (including Grok's own auth file) happen without asking, and the gate is one keypress away from global always-approve, so the protection rests on the user reading each prompt.

Grok gates repository-controlled configuration behind a VS Code-style folder-trust decision: project MCP servers, hooks, permission rules, .envrc, agent definitions, skills and even AGENTS.md instructions are skipped until you trust the folder, and headless runs fail closed. Project files can't set the global permission mode. Once trusted, though, a repo's settings can turn on bypass mode, and project agents can declare their own always-approve mode. Cross-session memory is off by default; when enabled it captures facts after every turn without review. Builds made from source disable folder trust entirely.

No plugins or MCP servers are active on a fresh install, and project-shipped extensions wait for folder trust. Plugins you install, however, are re-fetched and updated automatically at the start of each session with no re-approval, so a compromised plugin update runs without anyone looking. MCP servers run as separate processes with your full environment.

Grok's own login token sits in a plaintext, owner-only file under ~/.grok, and nothing stops the agent's read tool from reading it without a prompt. Secret redaction exists but only on outbound telemetry, crash reports and the optional OpenTelemetry stream; it does not touch what is sent to the model, local transcripts or subprocess environments. Product telemetry and session-trace upload are off in code but can be switched on by xAI's remote settings.

Each session writes a local conversation transcript and a structured events.jsonl that records tool completions, MCP calls, permission requests and decisions, and always-approve toggles, under ~/.grok/sessions outside the project. The log is best-effort: write failures are logged once and work continues, the agent's own shell can edit it, and the sub-agent link in the event schema is never emitted.

Shell commands time out after 2 minutes by default (5 minutes maximum in the foreground), sub-agents are limited to one level deep and 32 concurrent, and stopping kills the command's process group. There is no default turn limit (--max-turns is opt-in), no wall-clock limit and no token or cost budget. Background commands may run up to 24 hours and the model can create durable scheduled tasks after approval.