The open-source desktop client for Grok Build.

Run multiple Grok Build sessions across your projects, follow their progress, and stay in control.

Install · Features · Getting started · Development · Contributing

Download the latest release

Grok Build is a powerful coding agent. Groky turns its local CLI into a persistent desktop workspace for projects, standalone tasks, and concurrent sessions.

• Persistent navigation: Group sessions by working directory, switch between active runs, reopen saved sessions, and keep archived work out of the main sidebar.
• Flexible starting point: Choose an existing folder or use a managed standalone directory created by Groky.
• Local integration: Groky launches the official Grok Build CLI on your machine and communicates with it over the Agent Client Protocol (ACP).
• Human in the loop: Review permission requests, choose an approval mode per session, and stop an active turn at any time.
• Focused interface: Follow Markdown responses, thoughts, plans, compact execution traces, live timing, usage, and turn metrics without leaving the app.
• Workspace tools: Browse and preview files, attach workspace files to a prompt, and use one or more interactive terminals from a resizable tools panel.
• Native desktop host: Process and filesystem access stay behind typed Tauri commands in the Rust host.

Groky runs the official Grok Build CLI on your computer. Install the CLI first, then choose the Groky package for your operating system.

Follow the official Grok Build installation guide. On macOS, Linux, or WSL:

curl -fsSL https://x.ai/cli/install.sh | bash
grok --version

Groky uses the official CLI as its agent runtime. You can sign in during Groky's onboarding flow, so starting an interactive grok session first is optional.

Groky checks GROK_BINARY, your PATH, ~/.local/bin, and ~/.grok/bin when locating the CLI. Set GROK_BINARY to the executable path if Grok Build is installed somewhere else.

Download Groky only from the official GitHub Releases page. Expand Assets and select the package that matches your computer:

Open the .dmg, then drag Groky into the Applications folder. macOS release builds are code signed and notarized by Apple.

Run Groky_*_x64-setup.exe and follow the installer. The Windows installer is signed for Groky's in-app updater, but it is not yet Authenticode code signed, so Windows SmartScreen may show an unrecognized-publisher warning. Confirm that the file came from github.com/ti-ebi/groky before continuing.

sudo apt install ./Groky_*_amd64.deb

Make the AppImage executable, then run it:

chmod +x Groky_*_amd64.AppImage
./Groky_*_amd64.AppImage

Files ending in .sig, .app.tar.gz, and latest.json are used by the signed automatic updater. You do not need to download them for a manual installation.

Start Groky from your Applications folder, Start menu, or application launcher. On first launch, Groky:

1. Detects the local Grok Build CLI.
2. Checks the CLI's cached authentication state.
3. Starts the official device-code flow when sign-in is required.
4. Restores locally tracked working directories and session navigation metadata.
5. Lets you choose an existing folder or a standalone location, approval mode, model, and reasoning effort.
6. Creates the Grok Build ACP session only when you send the first message.

The verification code shown by Groky should match the code shown in the browser. The CLI detects approval automatically; there is no token or code to paste back into Groky.

Groky can also use an existing XAI_API_KEY environment variable when the CLI advertises that authentication method. Groky does not persist the key.

Standalone sessions use a unique directory inside Documents/Groky/YYYY-MM-DD/. Removing a session from Groky history does not delete the files in that directory.

Session titles start from the first message or attachment name and can be renamed later. Saved sessions can be reopened when the installed Grok Build version advertises ACP session loading.

The tools panel's Files tab follows the active session, watches its working directory for changes, previews supported files without leaving Groky, and can attach a selected file to the next message. Each new Terminal tab runs your system shell in the working directory that was active when the tab opened. You can open multiple terminals, close tool tabs, and reorder tabs by dragging them or pressing Alt + ←/→ while a tab is focused.

When you switch sessions, Groky restores that session's panel visibility, width, open tabs, tab order, and selected tab. Running terminals and their scrollback stay attached to the session until you close the terminal tab or quit Groky.

Useful keyboard controls:

• Command/Ctrl + K searches sessions and common actions.
• Command/Ctrl + B toggles the sidebar.
• Command/Ctrl + J toggles the tools panel.
• Enter sends a message; Shift + Enter inserts a new line.
• Typing / opens the command catalog supplied by Grok Build.

React renderer
      │ typed Tauri commands and events
      ▼
Tauri Rust host
      │ JSON-RPC over stdin/stdout
      ▼
Grok Build CLI (`grok agent stdio`)

The React renderer does not start processes or access the filesystem directly. The Rust host owns CLI discovery, authentication commands, working-directory access and watching, file previews, terminal PTYs, ACP transport, permission responses, cancellation, and updates. Workspace file commands resolve canonical paths beneath the active session's working directory before reading or opening them.

ACP events are routed by session, so a turn can continue while another session is open. Groky stores lightweight navigation metadata locally and requests conversation replay from Grok Build when reopening a saved session.

Closing Groky stops active Grok Build processes, terminal sessions, and workspace watchers.

Grok Build itself handles model and network communication. Prompts and project context are processed according to xAI's Grok Build service and data policies; see the official Grok Build documentation.

• Groky delegates authentication to the official Grok Build CLI.
• Groky does not read or store the resulting browser-auth token.
• Groky stores session IDs, titles, working-directory paths, approval modes, timestamps, archive state, and unread state in the operating system's application-data directory. The initial title is derived from the first message or attachment name.
• Groky does not persist full conversation bodies or source-file contents in its own history files, and it does not write prompts, responses, credentials, or raw ACP traffic to application logs.
• Attached files are not copied into Groky. Their validated local paths and metadata are passed to Grok Build as ACP resource links.
• Files opened in the tools panel are read on demand for an in-memory preview. Text previews are capped at 512 KiB, font previews at 8 MiB, and supported image or PDF previews at 20 MiB.
• Terminal tabs run your local system shell with the session working directory as their current directory. Commands entered there have the same local access as that shell.
• Local processes and filesystem access are initiated through the Tauri Rust host, not the renderer.
• Deleting Groky history does not delete files in the associated working directory.
• Always approve skips individual prompts unless a policy rule still requires approval. Use it only in a working directory you trust.
• The Grok Build CLI and xAI service may retain their own session data independently of Groky; consult the official documentation for their behavior and policies.

Requirements:

• Node.js 24 or later
• pnpm 10
• Rust 1.88 or later
• Grok Build CLI

Clone the repository, install dependencies, and run the desktop application:

git clone https://github.com/ti-ebi/groky.git
cd groky
pnpm install
pnpm tauri dev

To preview the renderer without starting local processes:

pnpm dev

• Tauri 2 and Rust
• React 19, TypeScript, and Vite
• xterm.js with a Rust-hosted pseudoterminal
• pnpm
• A typed ACP client powered by Grok Build's grok agent stdio

pnpm check
cargo fmt --manifest-path src-tauri/Cargo.toml --check

pnpm check runs the frontend typecheck and build, TypeScript timing tests, all Rust unit tests, and cargo check.

Community contributions are accepted through GitHub Issues. Read CONTRIBUTING.md before submitting a report or proposal.

• Search existing issues before opening a new one.
• Use the appropriate form for a bug, feature request, or documentation improvement.
• Keep each issue focused on one topic and remove sensitive information from all reports and attachments.
• Do not open a pull request unless a maintainer invites you to implement an accepted issue.

Groky is available under the Apache License 2.0.