HackerAI runs its agent loop in a cloud sandbox behind seven required accounts

Seven required services stand between a clone and a running agent

The getting started sequence is short, and the prerequisite list is where the real weight sits. Seven services are marked required: OpenRouter as the AI model provider, OpenAI, E2B for isolated cloud execution in Agent mode, Convex for the database and backend, Amazon S3 for file storage, WorkOS for authentication and user management, and Trigger.dev as the durable runtime for agent tasks. Seven more are optional: abliteration.ai, Perplexity for web search, Jina AI for URL content retrieval, Redis for stream resumption, Upstash Redis for rate limiting, PostHog for analytics and Stripe for payments.

The install flow itself is four commands, and the third one repeats work the second one already did:

git clone https://github.com/hackerai-tech/hackerai.git

cd hackerai

pnpm install

pnpm run setup

The `setup` script is `pnpm install && npx tsx scripts/setup.ts`, so following the steps in order installs the same dependency tree twice. After that, `pnpm run dev` starts the Next.js and Convex dev servers together, or you can run `pnpm run dev:next` and `pnpm run dev:convex` in separate terminals. The `predev` hook fires `pnpm run check:local-dependencies` before any of them, so the dependency check runs before the dev server and again before `dev:next` and `dev:all`.

OpenAI's key is a classifier, not the model provider

Two model providers appear in the prerequisite list and they do different jobs. OpenRouter is the AI model provider that supplies models. The OpenAI entry is described narrowly: it identifies security requests that should use abliteration.ai models. In other words, the OpenAI credential is spent on classification so the request can be routed, not on generating the answer itself.

The destination of that routing is listed as optional. abliteration.ai is there for AI models for security requests that standard models may refuse. So the architecture has a built-in path that moves a request, when a classifier says the request is a security one, onto a provider chosen because the mainstream models decline it. That is a deliberate design choice rather than an accident, and it is written down plainly in the prerequisites.

Wiring it takes one key in three places: create a key in the abliteration.ai console and set `ABLITERATION_API_KEY` in `.env.local`, Vercel, and Trigger.dev. Without that optional key, the application continues using its standard models. Anyone running this in an environment with model policy constraints should decide about that layer before the first request, since the routing decision is made by a model call rather than by a rule you can read.

Agent mode executes in E2B's cloud, so the target boundary is the missing piece

E2B is a required dependency for a specific reason: isolated cloud execution in Agent mode, and Cloud Agent execution currently uses E2B. The agent loop itself runs as a Trigger.dev task, so the path for an agent request is a hosted queue, a hosted worker and a hosted sandbox. Nothing in the getting started material runs a command against a target from your own machine.

That architecture is the right one for the job, and it is also where the documentation thins out. Nothing on the page states which targets are permitted, and there is no documented allowlist, no dry-run mode and no abort switch for a run that is already executing. The tool's own premise, that an agent may take actions you have not enumerated, is the premise the safety documentation would normally cover, and this page does not. For an authorized engagement the scope belongs to you before the first request, not to a flag in this repository.

The isolation boundary is also not the only one to hold. Results and artifacts live in Amazon S3, user identity runs through WorkOS, and state lives in Convex, so an authorization mistake crosses three hosted systems at once rather than staying inside one sandbox.

MIOSA is paused in code while a stale override keeps selecting Docker

The most tangled paragraph on the page is about a subsystem that is switched off. MIOSA execution and migration are paused in code, including explicit provider overrides, and MIOSA_API_KEY has to be retained when cleanup or recovery of existing MIOSA files is needed. Before the rollout resumes, the instruction is to follow the MIOSA runbook at `docs/miosa-pro-pilot.md`.

The configuration state is where this bites. New Miosa workspaces default to the native `hackerai-tools` template, and `MIOSA_TEMPLATE_ID` can override that. But an existing `miosa-sandbox-docker` override still selects the Docker template, so it has to be removed or updated in each intended runtime for the native default to apply. Existing workspaces retain their original runtime and files, and migrated workspaces need verified recovery before they can use E2B, with their retained E2B source possibly stale.

Read as an operations note, that is four distinct states to reconcile by hand: new workspaces on the native template, untouched workspaces on whatever they started with, migrated workspaces waiting on verified recovery, and any workspace still carrying the Docker override. A paused feature whose key must be retained and whose template override must be manually swept is a good reason to inventory the values before resuming anything.

Privileged credentials get copied into a third-party worker dashboard

The Trigger.dev setup is a numbered sequence, and step 2 is the one to read carefully. You create a project at cloud.trigger.dev and copy your dev secret key, the `tr_dev_…` form, into `.env.local` as `TRIGGER_SECRET_KEY`. Then, in the dashboard under your project and Environment Variables, you add the variables the task needs, with the note that these live on the worker and not on Vercel: `NEXT_PUBLIC_CONVEX_URL`, `CONVEX_SERVICE_ROLE_KEY`, `OPENROUTER_API_KEY`, `OPENAI_API_KEY`, `AWS_S3_ACCESS_KEY_ID`, `AWS_S3_SECRET_ACCESS_KEY`, `AWS_S3_REGION`, `AWS_S3_BUCKET_NAME` and `E2B_API_KEY`, plus any optional keys you use, such as `ABLITERATION_API_KEY`, `PERPLEXITY_API_KEY` or `JINA_API_KEY`.

So there are two configuration surfaces holding the same secrets, and one of the entries is the Convex service role key, which is the credential that skips per-user authorization in a database that otherwise authenticates every request through WorkOS. Paired with S3 access keys and an E2B key, a hosted worker dashboard ends up holding the keys to your database, your file bucket and your execution sandbox. None of that is unusual for a job of this shape, and the dev secret key rather than a production one is the safer of the two choices, but it is the concrete security surface of running this locally rather than a local-only setup.

A local Trigger branch override can point the worker at the wrong queue

Agent mode runs the agent loop on a Trigger.dev task, and to use the agent locally you start the worker in a third terminal with `pnpm dev:trigger`. That script is `node scripts/trigger-dev-branch.mjs`, so the dev server, the Convex server and the worker are three terminals by design, with `pnpm run dev:all` there to run all three together.

The interesting part is the override. To start an explicitly routed Trigger.dev branch instead of the default worker, you set a stable branch name with `TRIGGER_DEV_BRANCH=my-local-agent pnpm dev:trigger`, and the instruction is to use that override only when the request path is configured to target the same Trigger.dev branch. The condition is doing the work here: a local worker started on a named branch will only receive requests that were routed to that branch, so a mismatch between the branch the worker listens on and the branch a request targets produces a run that never arrives rather than an error you can read.

The default path avoids the problem by starting the default worker used by local Agent requests. The override exists for when you need a separate queue, and it is a routing decision made in configuration on two sides, which is why the documentation ties it to a stable branch name.

The build uploads source maps to a service the prerequisites call optional

The build script is `next build && pnpm posthog:sourcemaps`, and the second half runs `node scripts/upload-posthog-sourcemaps.mjs`. The command is unconditional: nothing in the script chain gates it on a PostHog key being present. PostHog appears in the prerequisite list under optional, alongside Stripe and Redis, so the documented dependency level and the build behaviour do not line up. Whether the upload script short-circuits without a key is not stated, which means the safe assumption for a fork is that it does not.

The lint script has the opposite problem, a scope that is narrower than the tree. It runs `eslint app lib types __mocks__ --ext .ts,.tsx,.js,.jsx`, four directories, while the root also carries `components/`, `convex/`, `hooks/`, `scripts/`, `trigger/`, `e2e/`, `e2b/`, `docker/`, `__tests__/` and `packages/`. None of those is in the lint target, so the parts of a Next.js application that usually hold the most logic are outside the linter. Type checking is separate and broader in intent, since `typecheck` is `tsc --noEmit` over the project configuration.

CI is more interesting than either. `test:ci` is `pnpm skills:sync:strix:check && jest --ci --coverage --maxWorkers=2 && pnpm test:user-research-runner`, so the suite fails on a skills drift check before a single test runs. That check is `node scripts/sync-strix-skills.mjs --check`, and it guards skill files that live under `.agents/skills/`, with the user research runner tested separately by `node --test`. Nothing on the getting started page explains what strix is or where the sync source lives.

The release tags are a desktop app the getting started page never mentions

The three recent releases are all named for a separate product: `HackerAI Desktop` desktop-v0.0.57 on 2026-07-18, desktop-v0.0.58 on 2026-08-13 and desktop-v0.0.59 on 2026-08-17. Meanwhile `package.json` declares version `0.1.0` and marks the package `private`, so the repository is not published to a registry under that version line and the tags do not correspond to it. The desktop builds carry their own 0.0.x numbering and their own cadence, separate from the web application the getting started page describes.

The tree supports that reading without explaining it. There is a `packages/` directory alongside `pnpm-workspace.yaml`, which is where a separately versioned app would live, plus `docker/`, `e2b/`, `e2e/`, `third_party/`, `patches/`, `playwright.config.ts`, `jest.config.js`, `.husky/`, `proxy.ts` and `instrumentation.ts`. The desktop product is not named anywhere in the four setup steps, and no instructions for building it are given.

One more detail belongs with the licensing question rather than the releases. The repository's license metadata resolves to nothing recognizable, while the root carries both a `LICENSE` file and `THIRD_PARTY_NOTICES.md`, and the header links to the former. Those two facts do not settle each other, so read the files rather than the metadata before you reuse anything.

Editorial conclusion

HackerAI is worth reading if you are building an authorized security testing workflow and want to see how much hosted surface one implies. It is not something to point at targets you do not own, for three reasons visible in its own documentation: the agent loop executes in E2B's cloud rather than your machine, no page defines a permitted target list, and no page names a dry-run or an abort control. Before running it, settle three things. Read LICENSE, since the repository's license metadata resolves to nothing recognizable even though a LICENSE file and THIRD_PARTY_NOTICES.md sit in the root. Decide whether the abliteration.ai routing layer is acceptable in your environment, because OpenAI's key exists to classify which requests go there. And audit any existing MIOSA workspaces for a `miosa-sandbox-docker` override, which keeps selecting the Docker template after the native `hackerai-tools` default took over. If you only want the offline parts, the Next.js and Convex dev servers run without any of the agent keys.

Frequently asked questions

Official sources

1. hackerai-tech/hackerai on GitHub
2. Issues
3. Project website
4. README
5. Releases