Code agents (hosted runtime)

A code agent is the repository you already have — FindAgent runs it 1:1, unchanged. You don't rewrite it for the platform and you never write a findagent.json by hand: the submit flow reads the repo and generates the manifest from what's already there.

FindAgent reads the artifacts your repo already carries — an Anthropic DXT manifest.json, an MCP server config, your .env.example, package.json, and README — and auto-detects:

• Tools — the capabilities your code exposes, surfaced as the agent's skills.
• Credentials — the secrets your code needs, read from your DXT env and .env.example keys (never the values), each captured as a host-bound credential slot.
• Hosts — the external hosts your code talks to, derived into the default-deny egress allowlist.

You confirm or edit what was detected and submit. That's the 1:1 promise: the repo you bring is the agent that runs.

Code agents come in through the GitHub-connected submit flow — your own repo, gated by an OAuth token you authorize:

1. 1
   Connect GitHub. Authorize the FindAgent GitHub App so the platform can read the repo you choose. Only repos your connected token can read are reachable.
2. 2
   Pick the repo. Choose the repository to publish. FindAgent snapshots it and generates the manifest from the code — tools, credential slots, and the egress allowlist are detected for you.
3. 3
   Review & submit. Confirm the detected fields, set pricing, and submit. The bundle is statically scanned and human-reviewed before it can publish; a manifest the sandbox can't accept fails closed rather than being waved through.

When a code agent is approved, FindAgent builds it for the hosted runtime. The build installs dependencies and runs in the sandbox with a real node_modules — your code runs the way it does locally, not as a single flattened file.

• Native dependencies are supported. Packages with native add-ons — the better-sqlite3 / playwright / onnxruntime class — build and run, because the runtime keeps a full node_modules rather than bundling everything into one module.
• Prebuilds are fetched during the build. The build step reaches the package registries and prebuilt-binary hosts a native dependency needs, through an admin-managed build-egress allowlist.
• The build fails closed. If a native dependency can't fetch or compile its binary, the build is marked failed and the agent does not serve — a broken bundle is never shipped.

A code agent runs in FindAgent's hosted sandbox, so you use it by connecting your client to its gateway URL — there is no local npx install and nothing to keep running on your machine. The CTA on a code agent always reads Connect, never “Install”.

Add its remote MCP server URL — in the form https://mcp.findagent.cloud/agents/<slug> — as a connector in Claude, ChatGPT, Gemini, or any MCP-capable client, and sign in once. The full walkthrough is on the Connect page.

A code agent moves through build and readiness states after it's approved. The gateway only serves a ready agent:

Publishing a new version of an already-published code agent creates a fresh pending version and builds it separately — the live version keeps serving until the new one is approved, so an in-progress build never takes a working agent down.

Calls to a code agent over the hosted gateway are the metered surface — usage is recorded per call on the gateway path. This is what makes hosted code agents the primary, billable way to run real code on FindAgent. Offline local runs of declarative agents aren't metered, but a code agent only runs in the hosted sandbox, so its usage is always counted.

The security keystone is unchanged. Declarative agents ship no code at all; a code agent is the one kind that runs real code, and it runs only inside the isolated, ephemeral sandbox FindAgent provisions — walled off from FindAgent's own app and data, never your own machine, and only after a static scan and human review. The same default-deny egress, host-bound credentials, and platform-enforced guardrails apply. See the security model for the full reasoning.

• Manifest spec — the code-bundle manifest shape (entrypoint, runtime, allowed hosts, MCP exposure).
• Connect — add a hosted agent's gateway URL as a remote connector in your client.
• Creator guide — the submit wizard, pricing, and the review & scan pipeline.