xAI published the full Rust source code for Grok Build at github.com/xai-org/grok-build on July 14, 2026, under the Apache License 2.0 — days after a security researcher documented that the coding agent uploads repository and session state to xAI’s cloud by default. The repository has drawn 20,557 stars and 3,759 forks as of July 20, 2026, and was last updated on July 19, 2026.

Grok Build is SpaceXAI’s terminal-based AI coding agent: a full-screen TUI that reads a codebase, edits files, runs shell commands, searches the web, and manages long-running tasks. It runs interactively, headlessly for CI pipelines, or embedded in editors through the Agent Client Protocol (ACP). The published tree is synced periodically from the SpaceXAI monorepo, and a `SOURCE_REV` file records the exact monorepo commit each sync corresponds to.

What the Source Release Actually Changes

The source release makes Grok Build’s client-side data handling auditable, and it does not by itself change what the tool transmits. Developers can now read the code that stages and sends data rather than inferring behaviour from network captures — which is how the original finding was produced. Our earlier report on Grok Build sending code sessions to xAI documented researcher cereblab’s wire-level analysis showing repo_state and session_state uploads to a Google Cloud Storage bucket named grok-code-session-traces, active by default and unaffected by the “Improve the model” toggle.

xAI has issued no public statement connecting the source release to those findings. The repository carries no changelog entry addressing the upload behaviour, and open issues on the repository stand at 0 — external contributions are not accepted, and CONTRIBUTING.md states that explicitly. Server-side handling of uploaded data remains closed: publishing a client does not disclose what xAI’s infrastructure retains.

The .env Protection Exists — and Is Off by Default

Grok Build ships a kernel-enforced sandbox that can block specific credential files such as .env and *.pem from being read at all, and the documentation states plainly: “Sandbox mode is off by default.” The sandbox uses Landlock on Linux and Seatbelt on macOS, so the operating system enforces the limits for the process lifetime rather than the agent policing itself.

Grok Build offers 5 sandbox profiles, such as `off`, `workspace`, `devbox`, `read-only`, and `strict`. The `workspace` profile lets the agent read anywhere but write only to the working directory, `~/.grok/`, and temp directories. The `strict` profile confines reads to the working directory and system paths. Teams that need `.env` excluded must define a custom profile with a `deny` list, which is kernel-enforced for reads, writes, and renames, and supports glob patterns.

One caveat matters for macOS teams: child-process network blocking in the `read-only` and `strict` profiles is enforced on Linux only, through seccomp. On macOS it is a no-op, so those profiles do not restrict child-process network access there.

A separate permission layer authorizes each tool call through 5 ordered checks, such as PreToolUse hooks, permission rules, remembered grants, built-in auto-approvals, and the active permission mode. A matching `deny` rule rejects the call and overrides every other rule.

For Context: Grok Build and AI Coding Agent Security

How Grok Build Fits the AI Coding Agent Market

Grok Build competes against 4 established AI coding agents, such as Cursor, Claude Code, GitHub Copilot, and Google Jules. Its licensing tells part of the story: THIRD-PARTY-NOTICES records in-tree source ports from openai/codex and sst/opencode tool implementations, with Apache §4(b) change notices — Grok Build’s tool layer builds on existing open-source agent work rather than starting from scratch.

Installation runs through prebuilt binaries for macOS, Linux, and Windows, or a source build requiring Rust, DotSlash, and protoc. The binary artifact is named `xai-grok-pager`; official installs ship it as `grok`. First launch opens a browser for authentication.

Our Take
Open-sourcing the client is the right move, and it is reactive rather than proactive. The more revealing detail is what the source reveals: Grok Build already had a kernel-enforced mechanism to block .env files from being read — and shipped with it turned off, while session uploads shipped turned on. That pairing of defaults is the actual story. For businesses evaluating any AI coding agent on production repositories, the checklist is now concrete: what does it transmit by default, where does it stage data locally, which protections exist but are disabled, and does the vendor publish enough for you to verify the answers yourself? Grok Build now passes the last test. It still fails the first.

Frequently Asked Questions

Is Grok Build open source?

Yes, partially. xAI published the Rust source for the Grok Build CLI, TUI, and agent runtime at github.com/xai-org/grok-build under the Apache License 2.0 on July 14, 2026. xAI does not accept external contributions, and the server-side infrastructure that receives session data remains closed.

Does open-sourcing Grok Build fix the .env upload problem?

No. xAI has published no statement or changelog entry addressing the upload behaviour documented by researcher cereblab. The source release makes the client’s data handling auditable; it does not change the tool’s defaults.

How do I stop Grok Build from reading .env files?

Run Grok Build with a custom sandbox profile containing a `deny` list for credential paths. Sandbox mode is off by default and must be enabled explicitly with the `–sandbox` flag. Deny rules are kernel-enforced through Landlock on Linux and Seatbelt on macOS, and support glob patterns such as `**/*.pem`.

What is Grok Build?

Grok Build is SpaceXAI’s terminal-based AI coding agent, distributed as the `grok` command. It runs as a full-screen TUI that understands a codebase, edits files, executes shell commands, searches the web, and manages long-running tasks — interactively, headlessly for CI, or embedded in editors via the Agent Client Protocol.

Share.

I am a software engineer, I have a passion for working with cutting-edge technologies and staying up-to-date with the latest developments in the field. In my articles, I share my knowledge and insights on a range of topics, including business software, how to set up tools, and the latest trends in the tech industry.

Comments are closed.

Exit mobile version