HackerAI: a chat interface over a Trigger.dev agent loop
Find and fix vulnerabilities by chatting with AI
At a glance
- What is it?
- HackerAI is a TypeScript and Next.js application that turns vulnerability hunting into a conversation, running its agent loop as a Trigger.dev task with E2B sandboxes for execution. The interesting part is the operational surface area, not the chat UI.
- Who is it for?
- Adopt HackerAI if you already run Convex, WorkOS and Trigger.dev, or are willing to, and you want the agent loop to execute in an E2B sandbox rather than on your laptop. Do not adopt it if you need a self-contained CLI scanner, or if the Apache 2.0 with commercial restrictions licence is incompatible with how you plan to use it.
- 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 received new commits within the last day.
- What is it written in?
- Mainly TypeScript, 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 HackerAI is aimed at
Most vulnerability tooling splits into two halves that do not talk to each other. A scanner produces findings, and a human reads them, decides which matter, and writes up what to do. HackerAI collapses that into a chat window. The README describes it as an AI-powered penetration testing assistant, and the repository description is blunter still: find and fix vulnerabilities by chatting with AI. The intended user is someone doing security work who would rather describe a target and iterate in conversation than wire up a scanner and triage its output. That is a real workflow difference, not a cosmetic one, because the agent can be told to try something specific and report back. What it is not is a replacement for a scanner you point at a CIDR range and leave running. The chat framing puts a human in the loop on every step by design.
Where the agent loop actually executes
The architecture detail that matters most is buried in the setup instructions rather than the feature list. Agent mode runs the agent loop on a Trigger.dev task, and the README calls Trigger.dev a required durable runtime for agent tasks. That word, durable, is doing real work. The loop is not a request handler that lives and dies inside a Next.js route. It is a task on a separate worker, which is why the local setup needs a third terminal running pnpm dev:trigger alongside the Next.js and Convex dev servers. Execution of whatever the agent runs happens in E2B, described as isolated cloud execution in Agent mode. So the data flow is roughly: the browser talks to Next.js, state and backend live in Convex, auth goes through WorkOS, and the agent loop runs on Trigger.dev with E2B as the place code actually executes. That is four hosted services before you have done anything, and the README is explicit that the worker's environment variables live on the worker, not on Vercel. Anyone who has debugged a missing API key in a serverless deployment will recognise why that note exists.
Getting it running locally
The documented path is short. Clone the repository, cd into it, run pnpm install, then pnpm run setup, then pnpm run dev, which the README says runs both the Next.js and Convex dev servers. If you prefer separate terminals, pnpm run dev:next and pnpm run dev:convex do the same thing individually. Agent mode adds a third process. You create a project at cloud.trigger.dev, copy the dev secret key starting with tr_dev_ into .env.local as TRIGGER_SECRET_KEY, and start the worker with pnpm dev:trigger. The README also documents a routing override: TRIGGER_DEV_BRANCH=my-local-agent pnpm dev:trigger, with the caveat that you should only use it when the request path is configured to target the same branch. That caveat is worth taking seriously, because a branch mismatch would send requests to a worker that is not the one you just started, and the symptom would look like the agent silently doing nothing. The worker's Trigger.dev dashboard environment variables need NEXT_PUBLIC_CONVEX_URL, CONVEX_SERVICE_ROLE_KEY, OPENROUTER_API_KEY, OPENAI_API_KEY, and one cloud sandbox provider, plus optional keys for Perplexity, Jina, S3 and the rest.
The dependency list is the real adoption cost
Required accounts are OpenRouter for models, OpenAI for content moderation, E2B for sandboxed execution, Convex for database and backend, WorkOS for authentication, and Trigger.dev for the durable runtime. Optional ones cover S3 or Convex storage for files, Perplexity for web search, Jina AI for URL retrieval, Redis for stream resumption, Upstash Redis for rate limiting, PostHog for analytics, and Stripe for payments. That is a lot of surface area, and each service is a separate bill, a separate key rotation, and a separate place where a credential can expire. The moderation dependency is the one I would flag first. Routing model output through OpenAI for moderation means every agent response passes through a second provider, which shapes what the assistant is willing to say and adds a failure mode where a moderation outage stops the chat. The README lists it as required, not optional, so there is no documented bypass. The release cadence is also worth noting: the three most recent releases are all desktop builds, desktop-v0.0.57 through desktop-v0.0.59, spanning July to August 2026, which suggests active work on a packaged desktop client alongside the web application.
When HackerAI is the wrong tool
If your task is a scheduled scan of a fixed asset list with results landing in a ticket queue, this is the wrong shape. There is no documented headless mode, no CLI entry point, and no batch interface in the material provided. The chat interface assumes a person is present. The second limitation is the licence. The repository metadata reports NOASSERTION, while the README badge says Apache 2.0 with Commercial Restrictions and links to a LICENSE file. Those two signals do not agree, and I cannot resolve the discrepancy from the material available. Apache 2.0 with an added commercial restriction is not standard Apache 2.0, which matters if you plan to embed this in a product. Read the actual LICENSE file before you build anything on top of it. Third, the hosted-service dependency means an air-gapped environment is out of reach without replacing Convex, WorkOS, Trigger.dev and E2B, which would be a rewrite rather than a configuration change. This is not legal advice, and the licence question is the one I would resolve with someone qualified before shipping.
How this differs from running an agent framework directly
The obvious comparison is a general agent framework such as LangGraph or the OpenAI Agents SDK, where you write the loop yourself and choose your own execution backend. HackerAI makes that choice for you: the loop is a Trigger.dev task, the sandbox is E2B, the state is Convex, and the auth is WorkOS. The trade is control for a working starting point. With a bare framework you pick the sandbox and can swap it; here the README says one cloud sandbox provider is required, and the surrounding services are named specifically. On the other side, a framework gives you nothing in the way of a UI, persistence or user management, and HackerAI ships all three. The honest framing is that this is an application, not a library. If your goal is a pentesting assistant you can deploy and use, the assembled pieces save months. If your goal is to understand or control the agent loop in detail, you will spend that time reading someone else's orchestration instead.
Upgrade and maintenance reality
The README points coding agents at AGENTS.md, which suggests the project expects automated contributors and keeps its conventions written down. That helps if you fork. It does not help with the upgrade cost, which is dominated by the hosted dependencies rather than the TypeScript. Trigger.dev task definitions, Convex schema and functions, and WorkOS configuration all evolve on their own schedules, and a breaking change in any of them lands on you. The pnpm dev:trigger worker is the piece most likely to break quietly, because it runs out of process and its environment variables are configured in a dashboard rather than a file you can diff. If you deploy this, treat the Trigger.dev environment variable set as configuration you document and version somewhere, or the next person to stand up an environment will rediscover it the hard way.
Editorial conclusion
Adopt HackerAI if you already run Convex, WorkOS and Trigger.dev, or are willing to, and you want the agent loop to execute in an E2B sandbox rather than on your laptop. Do not adopt it if you need a self-contained CLI scanner, or if the Apache 2.0 with commercial restrictions licence is incompatible with how you plan to use it. Before you commit, verify the actual LICENSE text, confirm which cloud sandbox provider you intend to supply, and check whether the Trigger.dev worker needs every env var listed in the README or only the subset your usage exercises.
Community notes