cas_skill

This skill lets you automate and orchestrate the codex app-server via a v2 proxy, streaming JSONL with deterministic timeouts.

Python

42

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill tkersey/dotfiles --skill cas

SKILL.md10.6 KB

Overview

This skill runs a v2-only Node JSONL proxy that spawns a codex app-server and exposes an automation-friendly stream API. It provides lossless, evented JSONL I/O, auto-handles v2 approvals, and forwards unhandled server requests to an orchestrator with deterministic timeouts. Each proxy instance pairs with its own app-server child so you can run N isolated instances in parallel. The proxy is intended for programmatic control, session mining, steering active turns, and orchestrated automation.

How this skill works

The proxy performs the required handshake with codex app-server (experimentalApi: true) and reads/writes JSONL over stdio. It emits a persistent event stream (cas/fromServer, cas/toServer, cas/serverRequest, etc.) that includes raw app-server messages plus routing keys (threadId, turnId, itemId). Forwarded server requests are sent to your orchestrator for reply; unanswered requests time out deterministically and approvals are auto-accepted per configurable policy. You drive the app-server by sending cas/request, cas/respond, or cas/send messages into the proxy stdin and consuming events from stdout.

When to use it

You need programmatic control of codex app-server for automation or orchestration.
You want to mine sessions, list threads/turns, or export thread content for indexing.
You must steer active turns or resume threads from an orchestrator (turn/steer, thread/resume).
You need multiple isolated app-server instances running in parallel (N instance runner).
You want deterministic handling of server-initiated requests and timeouts for reliability.

Best practices

Run one proxy+app-server per instance and use per-instance --state-file to avoid shared state.
Treat the cas stream as the source of truth and route by derived threadId/turnId keys included in events.
Configure server-request timeouts (--server-request-timeout-ms) to fail fast in automation pipelines.
Use the provided cas_client.mjs wrappers for typed intent (resumeThread, steerTurn) instead of raw strings when possible.
Opt into dynamic tools only if your orchestrator can safely run external tool calls and return typed results.

Example use cases

Automated session mining: enumerate threads, read turns, and build an external search index.
Orchestrated agents: spawn subagents that send code patches or updates into live sessions via cas/request.
Parallel workers: run N isolated instances to process many workspaces concurrently with deterministic approvals.
Steering/resume flows: programmatically steer an active turn or resume threads from external triggers.
Tool execution bridge: forward item/tool/call requests to hosted tools and reply with results from the orchestrator.

FAQ

No. The proxy assumes codex is on PATH and runs app-server in the specified cwd; it does not require access to repo source unless your workflows do.

How are approvals handled in multi-instance runs?

Approvals can be auto-accepted or configured per-type (--exec-approval, --file-approval). Use --read-only to decline exec and file approvals for safe workers.