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 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 hosted code agent runs in FindAgent's sandbox, so you use it by connecting your client to its gateway URL — nothing runs on your machine and there's nothing to keep running. The CTA on a hosted code agent reads Get, 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 creator can also offer a code agent you run on your own machine instead of — or in addition to — the hosted option. A local code agent is downloaded and run by you via the FindAgent CLI, so it can reach your localhost and local tools. FindAgent never runs it: it runs on your computer, with your own access, like an npm package or a local MCP server.

• Hosted, local, or both. A code agent declares how it can serve. Hosted is the default; a creator may add a local option, or offer a local-only agent. A local-only agent has no hosted gateway URL — it is never run by FindAgent.
• Buyer-run, buyer-consented. When you run a local agent it executes with your user's access — it can read your files, use your local tools, and make network requests, just like any program you run. There is no FindAgent-enforced egress allowlist on a local run — your machine is the boundary.
• Review the source first. A local agent still passes the same automated scan and human review as any listing, but that is not a guarantee it is safe to run on your machine. Review the source before you run it — and if the source is private, only run it if you trust the publisher.
• Your credentials stay local. A local agent uses your own keys, set through the CLI; they stay on your machine and are never sent to FindAgent.

The listing's Setup section shows the exact run command and client-config snippet when a local option is offered. The security model explains the hosted-vs-local trust boundary in full.

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. A local code agent runs offline on the buyer's own machine, so — like any offline local run — it is inherently unmeterable and isn't 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 every listing passes a static scan and human review before it publishes. Where it runs depends on how it's served:

• Hosted — the code runs only inside the isolated, ephemeral sandbox FindAgent provisions, walled off from FindAgent's own app and data and from your machine, with default-deny egress, host-bound credentials, and platform-enforced guardrails.
• Local — the code runs on your machine with your own access; FindAgent never runs it and there is no platform-enforced sandbox or egress allowlist. The scan and review still ran, but they are not a guarantee it is safe to run — review the source first (like an npm package or a local MCP server).

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.