Testlane: repeatable sign-in for coding-agent verification

A coding agent can change a page or an API quickly. Verifying the change often needs a signed-in account, a browser context and a clear statement of what should happen. Passing a password through a prompt or copying a cookie into a conversation makes that workflow harder to manage.

We’re releasing Testlane 0.6.0 as an open-source public beta. It is a local credential broker for coding agents working with sandbox and test applications. The npm package is @testlane/cli; the command remains testlane. A human stores a dedicated test account’s password in the OS keychain; the broker signs in on the agent’s behalf and issues a session for a reviewed profile.

Built for our own ERP development

Testlane began as an internal tool at Ownstead Systems to help accelerate development of our custom ERP implementations. We were using coding agents to build and refine business software, and wanted repeatable sign-in for checking changes in sandbox and test environments.

The goal was to spend less time setting up authenticated test sessions and more time checking the change itself: which account is signed in, which operations it can perform, and whether cleanup leaves the test environment ready for the next run. We’re open-sourcing the broker so other developers can use that approach with their own applications and tests.

Why this matters for business software

In a business application, seeing a page load is only part of verification. A writer and a reader might both sign in successfully while having different permissions to change a record. An anonymous request should fail where an authenticated request succeeds. A test needs to establish the account, exercise the operation and record the result.

Testlane supplies the authentication step so those checks can be repeated. The application’s authorization rules and business behavior still need explicit tests. A reported account role does not prove that a protected operation is enforced correctly.

How the local broker works

A human reviews a secret-free profile containing the app origin, environment, account identity and session lifetime. The password is entered at a hidden terminal prompt and protected with Windows DPAPI, macOS Keychain or Linux Secret Service.

For each request, the broker applies its environment, host and lifetime policy, loads the origin-bound credential, signs in and appends an audit row before issuing the session. Production-tagged profiles and declared production hosts are refused. The configuration needs to identify them correctly; Testlane cannot discover that an undeclared host is production.

Developers can use the CLI or run a local MCP server over stdio. When the consumer shares the broker’s filesystem, the managed session-file tool returns a path, expiry and release handle without placing cookie values in the tool result. After loading the file into a browser context, the consumer can release it. Expiry and normal disconnect also trigger cleanup; forced termination can leave a file behind.

The inline session tool remains available for consumers that need credential values. Issued cookies, files and handoff URLs are live credentials and should be treated accordingly.

What developers can try in this beta

• Pin Testlane in an existing app’s package lockfile and point MCP at that local installation.
• Run passive setup diagnostics for the registry, platform store prerequisites, optional browser dependency and audit path, with JSON output for automation.
• Explicitly request a fresh sign-in and identity check when credentials and app connectivity need verification.
• Use a Playwright fixture with separate accounts for roles and parallel workers, fresh browser contexts and temporary-file cleanup.
• Run the shipped smoke and two-role feature workflows with the app’s own Playwright dependency and inspect sanitized reports.

The workflow templates currently accept loopback targets only. The feature workflow requires a trusted test-environment receipt and permission to create, update and delete a disposable record. These are bounded starting points to adapt and review for a particular application.

Scope and limits

Testlane requires Node 22 or newer. Linux needs an unlocked Secret Service keyring for unattended use; the platform guide covers headless environments. App login compatibility depends on the configured strategy, so start with the existing-app quickstart and compatibility notes.

The broker does not isolate other processes running as the same OS user. A remote browser cannot open a path on the broker’s local filesystem. Removing a session file does not revoke copies already loaded into a browser; the application controls server-side validity.

This is a pre-1.0 public beta without an independent security audit. Full client-driven browser workflows and Codex acceptance remain unverified. The compatibility guide records which package and client versions were tested; use the matching GitHub release for that artifact’s manifest and proof files.

Start with one authenticated check

Visit the Testlane product page for an overview. Install the scoped npm package with npm install --save-dev --save-exact @testlane/cli@0.6.0.

The Testlane repository includes the existing-app quickstart, project installation guide and compatibility notes. Testlane is licensed under Apache-2.0.

Begin with a disposable nonproduction account: confirm its identity, open a protected page and check that an anonymous API request is refused. Then add the role boundaries and business operations that matter for your application.

We welcome concrete feedback through GitHub issues: the login flow you need, the step that failed, or the evidence you expected to receive. Remove credentials and private app details before sharing a report.