Let your agentverify the app.Signed in.
Keep dedicated test passwords in your OS store. Let Testlane sign in and give your local browser the session it needs to check the app you’re building.
npm install --save-dev --save-exact testlane@0.5.1
Open source · Apache 2.0v0.5.1 · npm pending
Inspect setup before using a stored credential.
npx --no-install testlane doctor --json
// Illustrative, abbreviated diagnostic report
{
"ok": true,
"checks": [
{ "id": "registry", "status": "pass" },
{
"id": "authentication",
"status": "warn",
"code": "authentication.not_requested"
}
]
}Ask MCP for a broker-owned temporary file.
const file = await mcp.callTool({
name: "session_file",
arguments: { profile: "shop:testing:qa" }
});
// Illustrative file.structuredContent metadata
({
id: "<opaque cleanup id>",
path: "/tmp/testlane-session-files-…/….json",
format: "storage-state",
expiresAt: "<broker artifact expiry>"
})Use the session, then release resources in finally.
const state = file.structuredContent;
let context;
try {
context = await browser.newContext({
storageState: state.path
});
const page = await context.newPage();
await page.goto("http://localhost:3000/account");
await expect(page.getByRole("heading", {
name: "Your account"
})).toBeVisible();
} finally {
await Promise.all([
mcp.callTool({
name: "release_session_file",
arguments: { id: state.id }
}),
context?.close()
]);
}Illustrative examples, abbreviated for clarity. Supply your own profile, MCP client and app checks. Full session recipe
Put authenticated access to work
What would you like
your agent to verify?
Give the agent a specific task, an approved account and checks that prove the result.
“I changed the account page. Sign in as the approved QA user and check the page, its identity endpoint and access without a session.”Existing-app quickstart
Prove the intended user can use it.
- 1Sign in with the QA profile
Load the local session into a fresh browser context.
- 2Check identity and page content
Assert the expected user and the protected page’s heading.
- 3Exercise both sides of access
Check the authenticated API response and an anonymous
401or403, as your app specifies.
“Check this feature as a writer and a reader. Create one disposable record, verify permissions, then remove the record and local session files, and close both browser contexts.”Writer / reader recipe
The shipped template is loopback-only and needs your app adapter and a trusted, fresh environment receipt.
Check the permission, then the state.
- 1Create through the writer
Use a disposable record and verify it through the API.
- 2Read through the reader
Confirm the other account can see the intended record.
- 3Deny a write; verify no mutation
Assert a 403 and unchanged stored state. Then verify the disposable record was deleted, remove local session files and close browser contexts.
“Run these Playwright checks in parallel. Map each worker and role to its approved account, keep browser state separate, then remove the local session files and close browser contexts.”Role and worker fixture
Separate identities for separate work.
- 1Map parallelIndex + role → profile
Map each worker and role to a distinct, preseeded account profile.
- 2Start a fresh context for each test
Keep browser sessions separate and run your own assertions.
- 3Close contexts and release state
Cookie isolation does not isolate app records or other test runs. Supply suitable application data fixtures too.
Illustrative tasks for your configured checks; nothing on this page executes against an app. The core broker supplies authentication. Optional Playwright templates supply reviewed verification recipes. Install in your project
Watch the handoff
One local session.
A clear chain of responsibility.
Testlane brokers the sign-in. Your Playwright checks decide what passes, and your client or workflow records the results.
- Human setup01
Approve a profile
Dedicated test account
- Agent / MCP client02
Request a session
session_file - Testlane broker03
Policy, sign-in & audit
Before file issuance
- Shared filesystem04
Return a local file
Path + cleanup ID
- Your Playwright checks05
Verify the app
Identity · page · API
- Client / workflow06
Clean up. Report.
Release file + context
A human approves the account and origin.
Review the profile and seed its dedicated sandbox credential in the OS-backed store.
reviewed profile → OS credential storeThe agent asks for an approved profile.
An MCP client requests a session file without putting a stored password into the prompt.
session_file({ profile: "shop:testing:qa" })The broker checks policy before credential use.
Testlane signs in through the configured adapter. A successful audit append is required before it issues the session file.
policy → credential store → app sign-in → auditThe tool returns a path and cleanup metadata.
The browser needs the same filesystem. The local file contains session credentials; the tool result contains metadata.
{ id: "<cleanup ID>", path: "<local file>", … }Your checks load the session and assert behavior.
Use the intended identity to check the page and API. These assertions belong to your app or configured recipe.
browser.newContext({ storageState: state.path })The client releases resources and records results.
Release the broker’s file and close the browser context in finally. File deletion does not revoke the app’s session.
release_session_file({ id }) + context.close()Six steps · 13-second loop · no live requests
Built into our release work
How we use it at
Ownstead Systems.
For our 0.5.1 release verification, we installed the exact package tarball in an isolated project, generated sandbox accounts in a reference app, and ran real Chromium browser and API checks.
The same hosted 0.5.1 artifact bytes passed nine consumer checks on Windows DPAPI and Linux Secret Service. A scoped Claude Code 2.1.268 run exercised four MCP tools: list_profiles, check, session_file and release_session_file.
These release checks use generated reference apps and accounts. Claude coverage is the scoped four-tool sequence; full client-driven browser workflows and Codex acceptance remain unverified.
Read the tested contracts- 01 Pack once
- 02 Install isolated
- 03 Verify identity & permissions
- 04 Release files & clean records
{
"diagnostics": true,
"mcpBrowser": true,
"disconnectCleanup": true,
"smokeCommand": true,
"featureCommand": true,
"noRetainedSessionFiles": true,
"noCredentialLeak": true
}Abridged results from these generated-account checks.
Know the boundary
Useful access.
Explicit limits.
Testlane reduces stored-password exposure in normal agent workflows. It is pre-1.0 software for dedicated sandbox and test credentials, and has not had an independent security audit.
Read the threat model- Declare your environments.
- Production profiles and declared production hosts are refused. Testlane does not automatically discover which systems are production.
- Keep the file consumer local.
- MCP session-file delivery needs a shared filesystem. It does not transfer state into a remote browser worker.
- The app owns session validity.
- A copied cookie can outlive the broker’s artifact expiry. Deleting the file does not revoke the app’s session.
- The OS user remains a trust boundary.
- Processes running as the same OS user can access user-scoped stores and session files. Use an appropriate account and execution environment.
Where we’re going
Local first. More to come.
Hosted workflows and paid plans are planned. The current local broker is being prepared for public beta. Tell us which parts of your verification workflow need a better handoff.
Put it to work