gawkbot: an open source Grok Bot that gates every write behind your click
open source grok bot. gawk bots automate your menial work via AI models and build you microapps to manage the outcome, so that you have a false sense of control.
At a glance
- What is it?
- gawkbot is a Go-based, self-hosted agent runner that turns a described workflow into a microapp with its own screen, schedule and tool allowlist. Its selling point is the approval gate: reads run free, writes wait for you.
- Who is it for?
- Adopt gawkbot if you already pay for Claude Code, Codex or Opencode and want scheduled, approval-gated workflows on your own machine with readable local state under ~/.wuphf/. Do not adopt it if you need per-bot cloud computers, a permissive OSI licence, or unattended writes to third-party accounts.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem gawkbot is aimed at, and the joke it makes about you
The README is unusually direct about its audience. gawkbot is for people who already pay for a coding agent CLI and want that subscription to do scheduled, repeatable work rather than one-off chat turns. The pitch is one sentence: describe the job, or demo it once on a call, and the system builds a bot that runs it, with its own screen, its own schedule and its own tools. The project positions itself against xAI's Grok Bot, which it describes as bundled with SuperGrok and Cursor paid plans, closed source, and running on xAI's cloud. gawkbot's counter-claim is that it is free, needs no account or seats, runs on your machine with your keys, and holds every send, commit, purchase and delete until you click approve. The name is a deliberate self-deprecation: grok means to understand profoundly, gawk means to stare openly and stupidly, and the README says it is named after the second one. The tagline about a false sense of control is the honest framing of what an approval gate actually gives you. You get a dashboard, and the bots keep working.
What a bot actually ships with: six parts, not a chat window
The README lists six components every bot gets. The app is a real screen that reads and writes workspace data. Routines are schedules expressed in plain terms such as every Monday at 9:00, with versioned prompts, run history and a transcript per run; new bots get a starter weekly routine derived from the workflow you described. Tools are self-authored capabilities such as scoring a lead or posting to a channel, and you teach more inside the bot's chat. Knowledge is a set of Wikipedia-style pages about the bot, where every claim is cited back to its source. Data and integrations cover the bot's own typed tables plus a claimed 1200+ integrations, connected once and shared across bots. The approval gate is the sixth part: reads are free, writes are held. That division between read and write is the design decision the rest of the product hangs on, and it is also where the friction lives, because a workflow that depends on a chain of writes will spend most of its time waiting on you.
How it runs: a Go binary, a Bun-built web UI, and an agent sidecar
The architecture visible in the material is three pieces. A Go binary is the entry point, built from ./cmd/wuphf, which is also the prefix for most environment variables. A web UI is built separately with Bun from the web directory. Routine execution runs on what the README calls a small sidecar service in agent/. The broker finds and supervises that sidecar automatically on source checkouts; WUPHF_AGENT_DIR points it elsewhere, and WUPHF_AGENT_URL is for when you manage the sidecar yourself. The web UI defaults to port 7891. Workspace state is stored as local files under ~/.wuphf/, which the README frames as a feature: bot knowledge, run transcripts and the company brain are files you can cat. For anyone who has debugged an agent by reading logs from a hosted dashboard, being able to open the state directory directly is a meaningful difference in how quickly you can tell what a bot did and why.
Getting it running: npx, global install, or a source checkout
The fastest path is npx gawkbot. The README states that the browser opens, you verify your runtime, name your office, and hand off your first workflow, landing on a live build feed beside a chat. A global install is npm install -g gawkbot followed by gawkbot. Building from source needs Go and Bun: clone the repository, run bun install and bun run build inside web, then go build -o gawkbot ./cmd/wuphf and execute ./gawkbot. The prerequisites are explicit: one bot CLI signed in, Claude Code by default, or Codex CLI or Opencode, and the first-run screen verifies the runtime before anything else happens. Flags include --provider with values claude-code, codex, opencode, ollama, hermes-agent and openclaw-http; --no-open; --web-port; --workspace, which applies to one command without changing the active workspace; and --unsafe, described as bypassing bot permission checks for local dev only. Custom OpenAI-compatible endpoints are configured through WUPHF_OLLAMA_BASE_URL and WUPHF_OLLAMA_MODEL, with a documented example pointing at a local proxy. Hermes Bot and OpenClaw gateways are reachable via --provider hermes-agent and --provider openclaw-http, with endpoints, models and auth overridable through WUPHF_HERMES_AGENT_* and WUPHF_OPENCLAW_HTTP_* variables or provider_endpoints in config. The README also offers a setup prompt to paste into Claude Code, Codex or Cursor, which points at AGENTS.md for conventions, ARCHITECTURE.md for internals and FORKING.md for forking.
Where it falls short: no per-bot computers, and a licence you must read
The comparison table in the README concedes a real gap. Against Grok Bot's one cloud computer per bot, gawkbot says: not yet, and describes its current model as a per-bot directory and tool allowlist on your machine. That is a weaker isolation boundary. A directory and an allowlist are policy, not a sandbox, so if you are running untrusted workflows or handing bots credentials to systems you do not control, the separation between bots is thinner than the marketing row implies. The licence is the second thing to check. The repository metadata reports NOASSERTION, and the README badge and table both name the Sustainable Use License, which is not an OSI-approved permissive licence in the way MIT or Apache 2.0 are. The README links to a LICENSE file but does not reproduce its terms, so anyone planning to fork, resell or embed gawkbot needs to read that file rather than assume. Third, the approval gate is a throughput ceiling by design. Every send, commit, purchase and delete waits for a click, so a bot whose value comes from acting while you sleep will not act while you sleep. The README even acknowledges this in its own comparison row, noting that Grok Bot's bots act around the clock while gawkbot's wait. That is the trade being made, and it is worth naming plainly rather than treating as a feature list item.
Alternatives, and what actually differs
The README names several open source alternatives and links to a longer comparison page: Rakazo, OpenMausBot and OpenBot, alongside the closed Grok Bot. The material does not describe how any of those three work, so the honest comparison available here is with Grok Bot, and the difference is structural rather than cosmetic. Grok Bot runs bots on xAI's cloud, picks the model for you, and lets them act on your accounts continuously; gawkbot runs on your machine with your keys, accepts a runtime you choose from a list that includes Claude Code, Codex, Opencode, local models, Hermes and OpenClaw, and inserts a human approval step before any external action. One is a managed service where the vendor holds the execution environment. The other is a local runner where you hold the environment and pay for it with your own attention. If your reason for wanting an agent is that you do not want to be in the loop, gawkbot is pointed the wrong way, and the README says so itself. The project's own site lists the other open source options; treat that page as the place to compare them, since this repository does not document their internals.
Maintenance, release cadence and upgrade cost
The release history shows a fast cadence: v0.238.1 on 2026-09-08, v0.238.0 five days earlier, v0.237.2 the same day as v0.238.0. Patch releases landing on the same day as minor ones suggests active iteration rather than long stabilisation cycles, and the version number itself, still in the 0.238 range, signals that the project has not declared a stable API. For a self-hosted tool that supervises a sidecar process and writes state under ~/.wuphf/, that means upgrades are not free. You are responsible for the Go and Bun toolchain on a source build, for keeping the agent sidecar reachable via WUPHF_AGENT_DIR or WUPHF_AGENT_URL, and for checking whether a new version changes the on-disk layout your bots depend on. The README does not describe a migration path or a state schema version, so before upgrading a workspace with live routines, back up ~/.wuphf/ and read the release notes for the version you are moving to. The command reference in the README is also truncated at gawkbot share, so the full set of subcommands is not documented in the material available here.
Editorial conclusion
Adopt gawkbot if you already pay for Claude Code, Codex or Opencode and want scheduled, approval-gated workflows on your own machine with readable local state under ~/.wuphf/. Do not adopt it if you need per-bot cloud computers, a permissive OSI licence, or unattended writes to third-party accounts. Before committing, check the LICENSE file for the actual Sustainable Use terms, read ARCHITECTURE.md and AGENTS.md for the sidecar contract, and confirm your runtime passes the first-run verification screen.
Community notes