Skip to content

[codex] Add PAGS browser runner runtime - #1

Merged
serge-ivo merged 1 commit into
mainfrom
codex/pags-browser-runner-runtime
Jun 20, 2026
Merged

[codex] Add PAGS browser runner runtime#1
serge-ivo merged 1 commit into
mainfrom
codex/pags-browser-runner-runtime

Conversation

@serge-ivo

@serge-ivo serge-ivo commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds the PAGS-first browser runtime foundation and publishes all current local platform changes in this branch.

This includes:

  • a generic local Playwright browser runner package with persistent profile storage, bearer-token protection, task state, events, approval gates, optional PAGS instance binding, request validation, and isolated JSON store state
  • pags runner CLI commands for starting the runner, checking local status, creating local tasks, cancelling/approving local tasks, registering a runner with PAGS, probing registered runtime status, creating/approving/cancelling PAGS-proxied tasks, and reading PAGS-proxied task events
  • CLI robustness fixes for async command errors, trimmed env/CLI values, encoded API path segments, concise connection failure output, and command-level tests for local cancel plus PAGS approve-task routing
  • instance-scoped runtime registration in the API with endpoint validation, encrypted runner-token storage when a KEK is configured, runtime status probing, task proxying, task approval/cancel proxying, event proxying, non-JSON runner response handling, and IPv6 localhost support
  • MCP runtime tools for registering/unregistering runners, checking status, running tasks, approving/cancelling tasks, and reading task events
  • PAGS-first runtime architecture documentation and browser-runtime store documentation
  • the current job application assistant agent scaffold and related console/auth updates that were present in the working tree and requested to be included

Architecture Notes

PAGS remains the control plane and brain/orchestration layer. Local or managed runners are capability executors. PAGS stamps proxied runner calls with X-PAGS-Instance-Id and normalizes runner task payloads before proxying, including forcing approval for browser.open.

The current runner auth is still MVP-grade: bearer token plus optional instance binding. Production hardening should move toward signed per-task requests or short-lived task tokens.

Validation

  • pnpm test passed: 306 tests
  • pnpm typecheck passed
  • pnpm lint passed
  • pnpm build passed
  • pnpm --filter @proagentstore/cli dev runner --help passed
  • CLI connection failure smoke passed with concise error output
  • live local runner smoke opened https://gotjob.online/ after approval and returned title GotJob - Find Your Next Great Job
  • staged secret-pattern scan found only false positives from task-events before the first push

@serge-ivo
serge-ivo force-pushed the codex/pags-browser-runner-runtime branch 3 times, most recently from c06f013 to 61f3c88 Compare June 20, 2026 01:00
@serge-ivo
serge-ivo force-pushed the codex/pags-browser-runner-runtime branch from 61f3c88 to 4c93ae1 Compare June 20, 2026 01:17
@serge-ivo
serge-ivo merged commit 4c93ae1 into main Jun 20, 2026
1 check passed
serge-ivo pushed a commit that referenced this pull request Jun 24, 2026
…lever)

Per the research, browser realism is the #1 factor in whether a remote
human's solve is even accepted (detection is at the fingerprint/IP layer,
not the click). Launch the real Chrome build (channel: "chrome") with its
own persistent profile when available — better TLS/fingerprint → fewer
CAPTCHAs trigger and logins persist across runs. Falls back to bundled
Chromium automatically if Chrome isn't installed; force Chromium with
PAGS_RUNNER_CHROMIUM=1.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
serge-ivo pushed a commit that referenced this pull request Jun 25, 2026
…honesty

#1 Deterministic & honest apply: a Board 'Apply to a job' panel posts to /apply and
shows the REAL returned task id (or the real error) — no chatbot that can claim
success without a task. resume_path is now optional (uses the uploaded résumé); the
apply tool's prompt forbids inventing task ids / claiming success on error.
#2 Setup checklist: Runner · Résumé · Profile status above the board, gating the
Apply button on runner+résumé so you can't start a doomed application.
serge-ivo pushed a commit that referenced this pull request Aug 29, 2026
…closed (#760)

A coding session on a managed-clone repo record that carries no `github_repo`
(GitHub coordinates absent) and no `workdir` (not a local-path checkout) was
allowed to start with `ghScope: undefined`. The runner treated absent scope as
"older cloud / not said" and installed NO gh guard — the Engine then ran with
unrestricted `gh` write access to any repository it could reach from the machine.

`gh-guard.ts` comment: "No scope is not 'allow nothing' — it is 'the platform
did not say'." That reasoning is correct for a legacy cloud, but wrong for a
record that is inherently incapable of producing a scope (stuck in `cloning`
with coordinates that were never resolved).

Fix: in `startSessionOnRunner`, after the connection check and before `callRunner`,
refuse the session when all three conditions hold:
  1. `repo.provider === "github"` — a `gh`-using remote
  2. `!repo.githubRepo`          — no coordinates to scope the guard with
  3. `!repo.workdir`             — not a local-path repo (which is exempt)

The concrete case: a duplicate `ProAgentStore/platform` record stuck in `cloning`
had a session attached to it. `coding_diagnostics` showed "1 of 2 tracked sessions
guarded"; the unguarded one was running on this broken record. Fixes ask #1 from
the issue.

Asks #2#4 (surface unguarded count as error, detect duplicate records, remove the
stuck data row) are owner/data-cleanup actions, not code changes.

Closes #760 (code guard half only — the stuck record `repo_2b2657fb` on the
operator account requires separate data cleanup).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants