Documentation

Sheet
D-100
Set
Docs
Status
Issued

How Fleet works, and how to connect

Concepts, the connection endpoint, the eight hosted tools, scopes, limits, troubleshooting, and the state of every capability.

D-100DocsIssued

What Fleet is

Fleet by Oracis is an independent engineering runtime for AI-assisted teams. Its workstation runtime carries bounded engineering workers, repository intelligence, research, review and repair, browser tools and missions; Oracis uses it every day. Its hosted service, which this page documents, is what an invited organization connects to: eight tools for jobs, independent validation, published checks and lessons. The capabilities page says which capability runs where.

Independent validation runs the repository's own verification policy against the exact commit, in a VM that exists only for that run. The result is a signed receipt; a separate publisher turns a receipt into a GitHub check, when a person asks it to.

GitHub remains where your code, pull requests and checks live. Fleet fetches read-only, runs checks on its own runners, and posts the result as a check through its own GitHub App. Nothing in Fleet pushes to your repository.

Fleet is a remote server for the Model Context Protocol (MCP). It is designed for any client that speaks the protocol. Today Claude Code is proven; Claude.ai, ChatGPT and Codex are designed for but not yet demonstrated (see Status).

Concepts

Organization
The unit of tenancy. Everything Fleet stores belongs to one organization, and one organization can never read another's jobs, validations, receipts or repositories.
Member and role
A person in an organization, identified by a verified email. Roles are member, admin and owner; the role decides the scopes below.
Repository connection
A github.com repository an organization owner has attested control of. A connection is made by the operator during the pilot and never moves between organizations.
Verification policy (profile)
The commands Fleet runs for a repository and the caps each lane gets. It is read from the repository's default branch, so a candidate commit cannot change its own policy: a commit that touches the policy's launcher files is refused as policy_changed.
Job
A bounded piece of engineering work with a spend ceiling in cents, admitted in one transaction with its reservation. It runs after you disconnect and survives a service restart.
Validation and receipt
A run of the policy against one exact commit. Each lane runs in its own VM. The receipt is a signed envelope that identifies the source, the policy and what the runner observed.
Publication
The publisher verifies a receipt against its pinned validator keys and posts a check-run on the commit. The check carries counts and ids only.
What a Fleet receipt binds A receipt lists the repository, the commit, the tree, the profile, the argv, the exit codes and the output hashes. It never carries raw output. repository commit tree profile argv exit codes output hashes never raw output What a Fleet receipt binds A receipt lists the repository, the commit, the tree, the profile, the argv, the exit codes and the output hashes. It never carries raw output. repository commit tree profile argv exit codes output hashes never raw output
Fig. 4A receipt identifies the exact source, the approved policy and what an independent runner observed. It carries hashes, never logs.

Connecting

The endpoint is a Streamable HTTP MCP server. A call without a bearer token is answered 401.

EndpointStreamable HTTP
https://fleet-api-fleet-api.up.railway.app/mcp

The current endpoint. A fleet.oracis.ai endpoint follows a separate, tested cutover; connections made to this address keep working for at least 14 days after it.

Sign-in uses OAuth 2.0 authorization code with PKCE (S256). Fleet's identity provider is Supabase Auth's OAuth 2.1 server; the consent page is Fleet's own. It shows the client asking, the host it will return you to, your identity, your organization and the exact scopes, and you approve or deny.

Connecting an MCP client to Fleet The client opens the browser and the browser reaches the consent page. The consent page shows identity, organization and scopes. The person approves, and the client is connected. client browser consent approve connected identity organization scopes Connecting an MCP client to Fleet The client opens the browser and the browser reaches the consent page. The consent page shows identity, organization and scopes. The person approves, and the client is connected. client browser consent identity organization scopes approve connected
Fig. 3Your MCP client opens the browser; the consent page shows who you are, which organization, and the exact scopes; you approve or deny.
  1. Add Fleet in your client.

    Paste the endpoint as a remote MCP server or custom connector. Client-specific steps: Claude, ChatGPT and Codex.

  2. The browser opens the consent page.

    Sign in with your email and password, or ask for an emailed sign-in link and return to the same tab.

  3. Read what is being asked.

    The client's name, the redirect host (a loopback address means a program on your own machine), your email, your organization and the scopes.

  4. Approve or deny.

    Approve returns you to the client with an access token bound to that client. Deny returns an error and nothing is issued.

  5. Call a tool.

    Your client lists the tools below. Read tools change nothing; write tools create, cancel or publish something and your client may ask you to confirm each one.

Where discovery stands. Today the 401 does not point at OAuth metadata and the server publishes no protected-resource document, so a hosted client cannot find the issuer from the endpoint alone. Claude Code's loopback flow is proven; the hosted Claude.ai, ChatGPT and Codex flows are unproven until the readiness work lands (see Status).

Tools

The hosted server exposes exactly 8 tools. None generates images, video or audio. The kind column is the truth from the code; the server does not yet publish readOnlyHint and destructiveHint annotations, and when it does they will say the same thing.

ToolKindScopeWhat it doesStatus
job_submit
Submit a job
write jobs:write Admits a bounded engineering job for a connected repository with a spend ceiling in cents. Returns a durable job id at once; the job runs after you disconnect. Implemented
job_status
Read a job
read jobs:read The state and event log of one job in your organization. A job in another organization answers not found. Implemented
job_cancel
Cancel a job
write jobs:write Cancels a queued or running job. A running worker is fenced out at its next lease renewal. Implemented
validate_submit
Validate a commit
write repositories:write Runs the repository's verification policy against one exact commit on an independent runner, each lane in its own VM. Returns a validation id. Implemented
validate_status
Read a validation
read repositories:read The lanes, their outcomes and the signed receipt of one validation your organization submitted. Implemented
publish_request
Publish a receipt
write repositories:write Asks the publisher to verify a receipt against its pinned validator keys and post it as a GitHub check-run on the commit. The check carries counts and ids only. Implemented
lessons_for
Lessons for this work
read jobs:read At most three lessons Fleet has recorded for work like yours in this repository. The task text you send is matched, not stored; the retrieval is recorded. Implemented
lesson_confirm
Confirm a lesson
write jobs:write Records whether a lesson you were shown held or did not, so the next retrieval is better ranked. Implemented

Permissions and scopes

Fleet defines six scopes. A member holds the first four; an admin or owner holds all six. The consent page lists the scopes a client asks for. Enforcement per tool is coarse today: a token that passes the identity checks can call any tool its role allows.

ScopeMeaningRoles
jobs:readRead jobs, their events and lessons in your organization.member, admin, owner
jobs:writeSubmit and cancel jobs; confirm lessons.member, admin, owner
repositories:readRead validations and receipts for connected repositories.member, admin, owner
repositories:writeSubmit validations and request publication.member, admin, owner
artifacts:readFetch job artifacts through short-lived download links.member, admin, owner
members:writeInvite, revoke and manage members.admin, owner

A token is accepted only if its signature, issuer, audience, expiry and not-before check out, its client is on Fleet's allow-list and its email is verified. A Fleet session lasts 8 hours; artifact download links last 15 minutes by default and at most 1 hour.

Data handling, in short

  • Your account: email, user id, role and organization. Fleet-issued tokens are stored only as hashes; your identity provider's access tokens are verified, never stored.
  • Your source: fetched read-only into a mirror on the validator, copied as an archive of the exact commit into a single-use VM, and the VM is destroyed. The mirror persists; a retention period is not yet defined.
  • Model requests: the API itself calls no model. A job's model calls go through OpenRouter with data collection set to deny on every request.
  • Logs: no per-request log and no IP address in the application; unexpected errors carry a reference id you can quote to support.
  • Retention: no automated deletion exists yet. Deletion is on request through support until the schedule ships.

The full inventory is the privacy policy; the third parties are on Subprocessors; the controls are on Security.

Limits

  • Job budget: 1 to 2,000 cents per job; at most 10,000 cents in flight per organization by default. The hosted cap starts at zero until the operator sets it, so a submission before that answers over_cap.
  • Requests: a 1 MiB body, 30 seconds for headers, 60 seconds in all.
  • Validator: 2 validations at once and a queue of 20 by default; beyond that a submission is refused, not silently queued.
  • Receipts: valid for at most 168 hours from issue.
  • Rate limiting: none yet beyond the bounds above.

Troubleshooting

401 on every call
No bearer token reached the server, or it expired (8 hours). Reconnect from your client so the consent page runs again. A token issued to a different client id is refused on purpose.
The consent page says to open it from the client
It was opened without an authorization_id. Start the connection from your client; it opens the page with the right parameters.
The emailed sign-in link opened in another browser
The link returns to the same page it was requested from. Open it in the browser where the consent tab is waiting, or start again from the client.
validator_unavailable: … (ref abc12345) or publisher_unavailable
The private service did not answer. Nothing was run. Quote the ref to support; it names the exact log line.
over_cap
Your organization's spend ceiling, or the fleet-wide cap, would be exceeded. Lower the budget or ask an owner.
policy_changed
The candidate commit changes the verification policy's launcher files, so it cannot be judged by its own policy. Land the policy change first, from the default branch.
A lane is incomplete with vm_destroy_unconfirmed
Fleet could not confirm the VM was destroyed and refuses to call the lane passed while the VM may exist. Resubmit; if it repeats, contact support.
Not found, for something you know exists
It belongs to another organization. Fleet answers not found rather than confirming existence across tenants.

Status

Each hosted capability and journey, with its status. The source is the Fleet readiness audit and live checks of 27 September 2026.

CapabilityStatusNote
Hosted MCP endpoint (Streamable HTTP, stateless)Proven live401 on every call without a bearer token.
Sign-in through the consent page from Claude Code (loopback callback)Proven liveA real Claude Code session signed in on 27 September 2026.
OAuth discovery from the endpoint (401 with resource_metadata; protected-resource metadata)PlannedToday a connector cannot find the authorization server from the endpoint alone.
Sign-in from Claude.ai and Claude Desktop (hosted callback)UnprovenDepends on discovery and on registering the hosted redirect URI.
ChatGPT connectorUnprovenNot yet demonstrated.
Codex (bearer from the sign-in helper)UnprovenConfiguration documented; not yet demonstrated end to end.
Tool annotations (title, readOnlyHint, destructiveHint)PlannedNot yet published by the server; this page states each tool's class from the code.
Per-tool scope enforcementPlannedScopes exist and roles map to them; enforcement per tool is coarse today.
Member profile (whoami) toolPlannedA view of your organizations, roles and repositories.
Hosted jobs (submit, read, cancel)ImplementedOn the live tool list; not yet demonstrated end to end for a customer.
Independent validation of a customer commitImplementedOn the live tool list; not yet demonstrated end to end for a customer repository.
Publishing a receipt as a GitHub checkImplementedOn the live tool list; not yet demonstrated for a customer repository.
Lessons for similar workImplementedDeployed; the first real call, 27 September 2026, answered with a defect Fleet is fixing.
Self-serve invitationsPlannedToday the operator provisions accounts.
Reviewer account with sample dataPlannedFollows the profile and invitation tools.
Retention and deletion schedulePlannedDesign milestone F4; deletion on request through support meanwhile.