Prasams OPS

Prasams Ops turns Codex into a governed software operator that builds, tests, deploys, visually verifies, recovers, and rolls back real applications.

Comment 1

## Inspiration

Coding agents have become remarkably capable at writing and understanding software. The harder problem is trusting them with real operational work.

A production change rarely ends with editing code. It may involve multiple repositories, tests, environment-specific configuration, Git commits, deployment approvals, SSH access, health checks, browser verification, recovery, and rollback.

Giving an agent unrestricted production access is dangerous. Restricting it to code suggestions leaves much of its potential unused.

We created Prasams Ops to close that gap: a policy and evidence layer between Codex and production. Our goal was to let Codex perform meaningful software operations while keeping project boundaries, permissions, approvals, secrets, and verification under deterministic control.

## What it does

Prasams Ops turns Codex into a governed software operator. Through a realtime dashboard or Telegram, an operator can describe a task in natural language and let Codex:

  • Inspect authorized repositories and runtime state
  • Diagnose problems using code, logs, processes, and service evidence
  • Edit code and run relevant tests
  • Commit and push changes
  • Prepare or execute exact-commit deployments
  • Follow environment-specific approval policies
  • Inspect rendered websites on desktop and mobile
  • Capture screenshots, console errors, network failures, and DOM evidence
  • Recover from bounded deployment failures
  • Prepare rollback actions
  • Record the complete workflow in an audit trail

Prasams Ops does not rely on prompts alone for safety. Projects, repositories, branches, deployment targets, SSH destinations, verification URLs, skills, and approval modes are stored in an explicit registry and included in every Codex task.

Codex supplies the reasoning. Prasams Ops supplies the boundaries, durable state, approvals, evidence, and recovery controls.

## How we built it

The Prasams Ops worker is written in TypeScript and integrates with the Codex SDK and persistent Codex app-server threads. It coordinates project workspaces, job state, attachments, skills, Git operations, deployment plans, browser verification, and recovery.

The web console uses React, TypeScript, Express, and SQLite. It provides realtime progress, multi-user roles, job-level permissions, deployment approvals, controller locks, project configuration, Codex authentication profiles, visual-QA artifacts, deployment history, and an audit trail.

The worker and dashboard communicate through a durable command queue. Commands are leased to eligible workers and renewed while active. If a worker disappears, its lease expires safely instead of allowing the same operation to run twice.

For browser verification, Codex can invoke Prasams Ops tools that inspect approved URLs and return screenshots, page metadata, console errors, network failures, and structured findings. After-deployment evidence can block a release when the rendered result does not meet its acceptance gates.

Prasams Ops existed before OpenAI Build Week as a working Codex operations platform. During the submission period, we meaningfully extended it using Codex with GPT- 5.6.

The largest Build Week addition was a guarded, resumable project-provisioning workflow. An administrator can now prepare and review a plan that:

  1. Creates or adopts a GitHub repository
  2. Creates the requested default branch
  3. Discovers the correct Cloudflare zone
  4. Prepares the DNS record
  5. Creates separate worker-write and hosting-read-only deploy keys
  6. Clones the repository into the worker and hosting environments
  7. Registers the new project and deployment target
  8. Verifies the completed foundation

Codex can inspect the available options and prepare a review-only plan, but it cannot approve or apply these external changes. Application requires an explicit administrator action.

Provisioning is persisted step by step, conflict-aware, idempotent, and resumable. If a run stops halfway through, it continues from the last verified step instead of duplicating repositories, DNS records, or deploy keys. Provider credentials are encrypted and are never exposed in Codex prompts or dashboard history.

Other Build Week additions included:

  • Direct routing of natural-language requests to Codex
  • Persistent continuation of the selected Codex thread
  • Protection against overlapping Codex turns
  • Branch and deployment policy inside every Codex project context
  • Account-wide Cloudflare zone discovery and guarded DNS replacement
  • An evidence-backed Quality Loop with bounded revision passes
  • A multisite-aware Brand Copy Editor with rendered desktop and mobile checks

Across the worker and dashboard repositories, these additions contributed more than 5,000 net lines of implementation, tests, and documentation.

Codex with GPT-5.6 helped us inspect the existing architecture, trace control paths, design contracts, implement TypeScript changes, write regression tests, review diffs, and verify deployed behavior. Important product and safety decisions remained deliberate human decisions.

## Challenges we ran into

The central challenge was balancing useful autonomy with deterministic control.

Codex is excellent at understanding intent, diagnosing failures, and adapting an implementation. Authorization, project boundaries, secret handling, approval policy, and destructive-operation limits should not depend on model judgment alone. We therefore enforce those controls in the surrounding runtime.

Provisioning also crosses several independent systems: GitHub, Cloudflare, SSH keys, remote machines, Git clones, and the project registry. Any step can fail or time out. We designed a persisted state machine where each step records its result and verifies existing external state before continuing.

Another challenge was preventing conflicting work. A dashboard user, Telegram user, or second browser could otherwise issue another instruction while Codex was still editing or deploying. We introduced command leases, job activity guards, and controller locks so only one authorized operation controls a job at a time.

Finally, we had to define what success actually means. A command can finish successfully while the application is broken, visually incorrect, or serving the wrong commit. Prasams Ops therefore treats tests, the exact commit SHA, remote state, health checks, screenshots, browser errors, and rollback availability as part of the result.

## Accomplishments that we're proud of

  • Building and operating a deployed product rather than a technical mockup
  • Creating one governed workflow from natural-language request to verified deployment
  • Implementing resumable provisioning across GitHub, Cloudflare, SSH, Git, and the project registry
  • Keeping consequential external changes behind administrator approval
  • Supporting exact-commit deployments, bounded recovery, and rollback
  • Adding browser evidence and deployment-blocking visual QA
  • Implementing multi-user permissions, controller locks, and audit history
  • Maintaining 185 passing worker tests and 143 passing dashboard tests
  • Extending an existing project transparently with substantial, documented Build Week work

## What we learned

We learned that safe agentic software is not created by removing autonomy. It is created by placing autonomy inside explicit, inspectable boundaries.

The most effective division of responsibility is:

  • Codex reasons, investigates, implements, and adapts
  • The control plane authorizes, constrains, records, and verifies
  • The human approves consequential transitions

We also learned that evidence is a better product primitive than status. “Deployment completed” is weaker than showing the exact deployed commit, passing tests, verified URLs, browser screenshots, and an available rollback.

Persistent context matters as well. Codex performs better when project identity, repository boundaries, deployment policy, previous decisions, and runtime evidence remain available throughout the workflow.

Finally, honest stopping conditions are essential. When Prasams Ops lacks authority or cannot verify an outcome, it reports the precise blocker instead of claiming success.

## What's next for Prasams OPS

Next, we plan to add more source-control, DNS, and hosting providers; reusable judge and development sandboxes; richer policy definitions; deployment-performance metrics; and stronger before-and-after visual comparison.

We also want to make installation easier for small teams by providing guided setup profiles and reproducible demonstration environments.

Our long-term goal is to make trustworthy Codex operations accessible to teams that need production-grade safeguards without building an entire internal developer platform.

Prasams Ops is our answer to a simple question:

What would it take to trust Codex not only to write a change, but to carry it safely all the way to verified production?

Share this project:

Updates