Files
PaperClipAI/server/src/services/setup-token-reaper.ts
T
Nicky LeachandPaperclip e0b64529b3 feat(auth): normalize agent login in the sandbox onto one session table and a capability contract (#11730)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - Sandbox agents need a safe login path for each supported adapter
> - Codex device login and Claude setup-token login used separate
session stores and route logic
> - Separate stores made session lookup, expiry, and login capability
checks harder to keep consistent
> - This pull request unifies both flows on one session table and one
capability contract
> - The benefit is one company-scoped login model with public session
identifiers and shared lifecycle rules

## Linked Issues or Issue Description

**Subsystem affected**

Cross-cutting (multiple of the above)

**Problem or motivation**

Codex and Claude sandbox login used separate session stores and
different route paths. This split increased the risk of inconsistent
company scoping, session lookup, and cleanup.

**Proposed solution**

Use `adapter_auth_sessions` for both login flows. Use public session
identifiers for API access. Select login behavior from projected adapter
capability data. Share the route spine, lease arguments, runner
lifecycle, and reaper rules.

**Alternatives considered**

Keep two session tables and add matching fixes to both routes. This
keeps duplicate logic and does not provide one capability contract, so
this pull request uses shared infrastructure.

**Roadmap alignment**

This change supports the shipped Cloud / Sandbox agents milestone in
`ROADMAP.md`.

## What Changed

- Unify Codex device login and Claude setup-token login on
`adapter_auth_sessions`.
- Return and look up sessions with company-scoped public session
identifiers.
- Enforce one active session for each company, owner, and adapter.
- Share the login route spine, sandbox lease arguments, runner
lifecycle, and missing-auth check.
- Add a standalone setup-token reaper with adapter-specific row
selection.
- Add optional login capability projection for adapters and drive route
and UI selection from that data.
- Rename the provider flag to `supportsLoginPty` and validate its
deprecated alias.
- Remove the old Claude setup-token session table and add the required
migrations.

## Verification

- Server typecheck passed with `tsc`.
- Database typecheck passed.
- UI typecheck passed with `tsc -b`.
- Codex login service and route suites passed.
- Setup-token session, route, and reaper suites passed.
- Adapter session schema, plugin validator, capability projection, UI
render, and Daytona suites passed.
- GitHub Actions must confirm the complete CI gate after pull request
creation.

## Risks

- The migrations remove short-lived in-flight login rows during
deployment. A login that spans the migration can continue until its
provider lease expires.
- The Codex credential store remains company-scoped. A cross-owner
credential race remains a documented, board-accepted risk.
- API clients that use internal session row identifiers no longer work.
The API accepts only public session identifiers.

## Model Used

Codex, GPT-5, exact runtime model ID not exposed in this handoff, large
context window, reasoning, and repository tool use. The implementing
engineer produced the code with AI assistance.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` /
`Closes: #` / `Refs: #` OR (b) described the issue in-PR following the
relevant issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
2026-08-19 11:51:31 -07:00

88 lines
3.5 KiB
TypeScript

import type { Db } from "@paperclipai/db";
import type { EnvironmentRuntimeService } from "./environment-runtime.js";
import { environmentService } from "./environments.js";
import {
reapSetupTokenLeases,
type SetupTokenCleanupStore,
type SetupTokenLeaseManager,
type SetupTokenReapResult,
} from "./setup-token-session.js";
import {
createProductionSetupTokenCleanupStore,
createProductionSetupTokenSandboxProvider,
} from "./setup-token-transport-binding.js";
// The restart-safe cleanup backstop for the Claude setup-token login flow.
//
// The in-process five-minute timer in the login-session service stays the
// primary control. This reaper is the backstop. It runs on server startup and on
// a fixed interval, so a sandbox lease survives a server restart and a release
// failure. The reaper reads the durable cleanup store and releases any lease
// whose session is terminal, past its deadline, or already consumed. It uses the
// same convention as the Codex device-login reaper, so both flows use one reaper
// convention.
//
// The reaper never records secret data. The durable cleanup record holds only
// ids, the deadline, the claim marker, and the state. It never holds a URL, a
// code, a token, or a raw process chunk.
/** The dependencies the standalone reaper needs. The reaper only reads reapable
* records and releases a lease by id, so it takes a store subset and a lease
* releaser, not the full session service. */
export interface SetupTokenReaperDeps {
store: Pick<SetupTokenCleanupStore, "listReapable" | "remove">;
leases: Pick<SetupTokenLeaseManager, "releaseById">;
now?: () => number;
log?: (line: string) => void;
}
/**
* Builds the standalone setup-token reaper. One sweep reaps every reapable
* record: it releases the lease and clears the row. A failed release stays
* retryable, so the next sweep retries it.
*/
export function createSetupTokenReaper(deps: SetupTokenReaperDeps) {
const now = deps.now ?? Date.now;
async function sweep(): Promise<SetupTokenReapResult> {
return reapSetupTokenLeases({ store: deps.store, leases: deps.leases, log: deps.log }, now());
}
return { sweep };
}
export type SetupTokenReaper = ReturnType<typeof createSetupTokenReaper>;
// ---------------------------------------------------------------------------
// The production runtime binding.
// ---------------------------------------------------------------------------
export interface ProductionSetupTokenReaperDeps {
db: Db;
environmentRuntime: EnvironmentRuntimeService;
log?: (line: string) => void;
}
/**
* Builds the production setup-token reaper. It reads the durable cleanup store
* and releases a lease by id through the production sandbox provider. The
* provider release resolves the lease and its environment from the database and
* tears down the remote sandbox through the driver, so the release frees the
* remote sandbox and not only the database row. The reaper never acquires a
* lease, so it binds no live pseudo-terminal opener.
*/
export function createProductionSetupTokenReaper(
deps: ProductionSetupTokenReaperDeps,
): SetupTokenReaper {
const environments = environmentService(deps.db);
const sandbox = createProductionSetupTokenSandboxProvider({
environments,
environmentRuntime: deps.environmentRuntime,
log: deps.log,
});
const store = createProductionSetupTokenCleanupStore(deps.db);
return createSetupTokenReaper({
store,
leases: { releaseById: (leaseId) => sandbox.release(leaseId) },
log: deps.log,
});
}