Background and context
AIHawk began under a repository name that still says Jobs_Applier_AI_Agent_AIHawk, and its public reputation grew around automated job applications. The current project is broader: an open-source AI browser agent. Give it a plain-language task and it uses a real browser to point, click, type, and read the page. It targets work where an API is missing or inadequate because the website itself is the interface.
There are two routes in. Claude Code, Codex, or Gemini CLI users can install invisible-playwright-mcp and connect it through Model Context Protocol; the assistant supplies the model. The standalone aihawk package provides a local web UI, with chat beside a live browser, and requires an OpenRouter key. Both use the same patched Firefox through the MCP server. The repository has 30,311 stars, an MIT license, and one open issue, showing considerable reach without proving reliability by itself.
What happened when we ran it
We cloned commit f27d421 into a fresh, unprivileged Debian container with three CPUs, 8 GB of RAM, Python 3.12, and no secrets. The checkout contained 116 files, about 6,398 lines of source, and occupied 2.7 MB.
Installation succeeded in 29 seconds, adding 79 packages that consumed 105 MB. The build succeeded in 6 seconds. Pytest completed in 15 seconds with 135 passed, zero failed, and six skipped, according to our measured run. pip-audit found zero known vulnerabilities. We also found five CI workflow files, a tests directory, and no Dockerfile.
That is a clean result: no dependency conflict, missing system-package detour, or build failure. It is not a live-site benchmark. Our sandbox had no credentials, and the run does not demonstrate success against a booking site, login, CAPTCHA, or bot defense. It also excludes the separate browser download, which the README puts at about 250 MB. The evidence says the Python project installs, builds, and tests cleanly in this environment—not that every browsing job will work.
What AIHawk does well
The documentation is unusually practical. Because the browser is fetched only when a page is first needed, a slow download can look like a stalled instruction. AIHawk recommends running invisible-playwright fetch beforehand, where progress is visible. It also explains a common PATH problem and offers python -m invisible_playwright_mcp as the fallback. Those details save real troubleshooting time.
Its controls cover common browser-agent needs. A proxy changes egress, locale, and timezone. A seed makes browser identity repeatable. A profile directory preserves cookies and logins, while headed mode exposes the browser window. An existing engine binary can skip downloading, although it must match the pinned version.
Credential handling gets more thought than in many local AI tools. Configuration precedence is flag, environment, local .env, then default. Startup names applied variables without printing their values. The OpenRouter key is removed from the browser process environment by both name and value, and a test guards this behavior. The README also warns that a command-line key can leak through shell history and the Linux process list.
The agent also refuses to set form fields directly through page JavaScript, preferring pointer and keyboard events because sites can detect the difference. That cannot defeat every defense, but it is a concrete sign that AIHawk is designed for real web conditions rather than a toy page.
Weaknesses and rough edges
Platform support is the biggest limitation. Python 3.11 or newer is required; Windows supports x86_64, Linux supports x86_64 and arm64, and macOS is unsupported because its last engine build was firefox-20. The extra browser fetch also makes the one-line pip command only part of the true setup and storage cost.
The standalone UI has no authentication. Loopback is the safe default, but changing the host exposes that unauthenticated interface. A team deployment therefore needs its own network boundary. The lack of a Dockerfile also leaves standardized container packaging to the operator.
Natural-language browser control carries an unavoidable trust problem. An agent can misunderstand a request, misread a changed layout, or perform a hard-to-reverse action. Explicit prompts and the instruction not to guess unavailable values help, but they are not guarantees. Applications, purchases, account changes, and messages need supervision until a workflow is proven.
Community health and release activity
Version 0.6.0 was released on September 4, 2026, and the repository was pushed again on September 5. Together with five CI workflows and the clean test run, that is good evidence of current maintenance. Only one issue is open, but that might reflect fast triage or work split among the MCP, engine, and core repositories. The supplied evidence shows one fresh release, not a historical cadence, so predictable release scheduling cannot be claimed.
About 30.3 thousand stars and coverage by major technology publications show awareness. Support may still require finding whether a bug belongs to AIHawk, invisible-playwright-mcp, invisible_playwright, or invisible_core. The README maps those boundaries and asks reports to include the failed step, page behavior, tool output, and exit country—a useful standard for actionable debugging.
Where it fits in a real stack
AIHawk belongs at the edge of an agent system, where model reasoning meets websites. Choose MCP when an existing compatible assistant owns the conversation and model. Choose the standalone UI for a local operator workflow when an OpenRouter key is acceptable. Keep conventional APIs for stable, structured integrations; use browser automation for gaps where only the human-facing page exposes the workflow.
Start with read-only research and comparison tasks. Add persistent profiles or proxies only when needed, and put approval gates before submissions, purchases, deletions, or communication. AIHawk's strongest case is not effortless automation. It is packaging the difficult browser layer, documenting sharp edges, and plugging it into tools people already use.