@christiandoxa/prodex 0.2.131 → 0.2.133

package/README.md

@@ -2,30 +2,24 @@
 
 [![CI](https://github.com/christiandoxa/prodex/actions/workflows/ci.yml/badge.svg)](https://github.com/christiandoxa/prodex/actions/workflows/ci.yml)
 
-Run multiple isolated Codex profiles on the same OpenAI account pool, with smart quota checks, clean profile separation, and continuation-aware routing.
+Run multiple isolated Codex profiles on the same OpenAI account pool.
 
-`prodex` helps you manage multiple Codex identities without turning your workflow into a mess.
+`prodex` is a small CLI for managing multiple Codex profiles without manually switching logins and local state.
 
-It is designed around a simple model:
+It uses a simple model:
 
 - **One account = one profile**
 - **Quota is checked before launch**
 - **Fresh work can move to another ready profile**
 - **Existing continuations stay with the profile that already owns them**
 
-That means you can keep working smoothly across multiple accounts while preserving session continuity where it matters.
-
 ## Why `prodex`?
 
-Not everyone wants to pay $200 for a single account.
-
-Sometimes it makes more sense to run 2 or 3 separate $20 accounts you already have. The problem is that doing it manually is annoying fast. You have to log in, log out, switch homes, check quota, and keep track of which session belongs to which account.
+If you use multiple accounts, doing everything by hand gets old quickly.
 
-`prodex` exists to remove that pain.
+A common case is having 2 or 3 separate $20 accounts instead of paying for a higher-tier plan. That works, but the workflow is annoying. You have to log in and out, switch homes, check quota manually, and remember which session belongs to which account.
 
-It manages isolated profiles for each account, checks quota before launch, routes fresh work to an available profile, and keeps ongoing continuations attached to the right one.
-
-Less account juggling, less friction, more actual work.
+`prodex` handles that setup by keeping profiles isolated, checking quota before launch, and keeping continuations on the profile that already owns them.
 
 ## Requirements
 
@@ -36,7 +30,7 @@ Before using `prodex`, make sure you have:
 - **Claude Code (`claude`)**, if you want to use `prodex claude`
 
 > Installing `@christiandoxa/prodex` from npm also installs the Codex runtime dependency for you.  
-> Claude Code is still a separate CLI and must already be available on your `PATH` if you want to use `prodex claude`.
+> Claude Code is still a separate CLI and should already be available on your `PATH` when you use `prodex claude`.
 
 ## Install
 
@@ -44,7 +38,7 @@ Before using `prodex`, make sure you have:
 
 ```bash
 npm install -g @christiandoxa/prodex
-```
+````
 
 ### Cargo
 
@@ -62,18 +56,18 @@ Check your installed version:
 prodex --version
 ```
 
-The current local version in this repo is `0.2.131`:
+The current local version in this repo is `0.2.133`:
 
 ```bash
-npm install -g @christiandoxa/prodex@0.2.131
-cargo install prodex --force --version 0.2.131
+npm install -g @christiandoxa/prodex@0.2.133
+cargo install prodex --force --version 0.2.133
 ```
 
 Dependency status in this repo:
 
-- The npm runtime dependency is already at the latest published `@openai/codex` release: `0.118.0`
-- `cargo update` currently produces no Rust lockfile changes on the Rust `1.94.1` compatible graph used by this project
-- `generic-array` remains pinned transitively by `crypto-common`, and `sha2 0.11` would require a wider RustCrypto compatibility jump than this release
+* The npm runtime dependency is already at the latest published `@openai/codex` release: `0.118.0`
+* `cargo update` currently produces no Rust lockfile changes on the Rust `1.94.1` compatible graph used by this project
+* `generic-array` remains pinned transitively by `crypto-common`, and `sha2 0.11` would require a wider RustCrypto compatibility jump than this release
 
 Switching from a Cargo-installed binary to npm?
 
@@ -97,7 +91,7 @@ prodex login
 prodex login --device-auth
 ```
 
-Want to name the profile first?
+If you want to name the profile first:
 
 ```bash
 prodex profile add second
@@ -120,11 +114,11 @@ prodex exec "review this repo"
 prodex claude -- -p "summarize this repo"
 ```
 
-> `prodex` without a subcommand is shorthand for `prodex run`.
+`prodex` without a subcommand is shorthand for `prodex run`.
 
 ## Common Workflows
 
-### 1. Create or import profiles
+### Create or import profiles
 
 ```bash
 prodex profile import-current main
@@ -132,7 +126,7 @@ prodex profile add second
 prodex login --profile second
 ```
 
-### 2. Inspect your pool
+### Inspect your pool
 
 ```bash
 prodex profile list
@@ -140,7 +134,7 @@ prodex quota --all
 prodex info
 ```
 
-### 3. Run Codex with automatic profile selection
+### Run Codex with automatic profile selection
 
 ```bash
 prodex
@@ -148,20 +142,20 @@ prodex run
 prodex exec "review this repo"
 ```
 
-### 4. Resume an existing session on the correct profile
+### Resume an existing session on the correct profile
 
 ```bash
 prodex run 019c9e3d-45a0-7ad0-a6ee-b194ac2d44f9
 ```
 
-### 5. Run Claude Code through the same profile pool
+### Run Claude Code through the same profile pool
 
 ```bash
 prodex claude -- -p "summarize this repo"
 prodex claude --profile second -- -p --output-format json "show the latest diff"
 ```
 
-For managed profiles, Prodex now seeds Claude state from your existing `~/.claude` and `~/.claude.json` on first use, then keeps Claude config and chat history in shared Prodex-managed state.
+For managed profiles, Prodex can seed Claude state from your existing `~/.claude` and `~/.claude.json` on first use, then keep Claude config and chat history in shared Prodex-managed state.
 
 ## Command Reference
 
@@ -237,9 +231,9 @@ That pointer path lives in `/tmp` only when you keep the default runtime log dir
 
 Use `prodex cleanup` to remove stale local runtime logs, temporary login homes, dead broker leases and registries, plus old orphaned managed profile homes that are no longer tracked in state.
 
-## Runtime Policy
+## Advanced Runtime Configuration
 
-Enterprise-style local deployments can pin runtime logging and proxy tuning in `$PRODEX_HOME/policy.toml` or `~/.prodex/policy.toml`.
+If you want tighter control over runtime logging, secrets, or proxy behavior, you can pin local settings in `$PRODEX_HOME/policy.toml` or `~/.prodex/policy.toml`.
 
 ```toml
 version = 1
@@ -262,38 +256,38 @@ stream_idle_timeout_ms = 300000
 
 Notes:
 
-* Environment variables still win over `policy.toml`.
-* `prodex info` and `prodex doctor` show the active policy file, selected secret backend, and effective runtime log mode.
-* The default runtime log format remains `text`; set `log_format = "json"` or `PRODEX_RUNTIME_LOG_FORMAT=json` when you want machine-readable runtime logs.
-* Secret backend selection can be overridden with `PRODEX_SECRET_BACKEND` and `PRODEX_SECRET_KEYRING_SERVICE`.
-* `prodex audit` reads the local append-only audit log and supports `--tail`, `--component`, `--action`, `--outcome`, and `--json`.
+* Environment variables still win over `policy.toml`
+* `prodex info` and `prodex doctor` show the active policy file, selected secret backend, and effective runtime log mode
+* The default runtime log format remains `text`; set `log_format = "json"` or `PRODEX_RUNTIME_LOG_FORMAT=json` when you want machine-readable runtime logs
+* Secret backend selection can be overridden with `PRODEX_SECRET_BACKEND` and `PRODEX_SECRET_KEYRING_SERVICE`
+* `prodex audit` reads the local append-only audit log and supports `--tail`, `--component`, `--action`, `--outcome`, and `--json`
 
-## Enterprise Hardening
+## Hardening And Operational Notes
 
-The current hardening is still local-first, but it now includes:
+The current setup is still local-first, but it already includes:
 
-- a secret-management abstraction for `auth.json` and exported profile bundles, plus global secret-backend selection via policy or environment
-- a stable live broker snapshot at `GET /__prodex/runtime/metrics`
-- a Prometheus scrape target at `GET /__prodex/runtime/metrics/prometheus`
-- `prodex info` and `prodex doctor --runtime --json` surfacing live broker metrics targets and the selected secret backend
-- enterprise audit logging for profile selection, rotation decisions, and admin-facing state changes, kept separate from transport behavior and discoverable via `prodex info` or `prodex doctor --runtime --json`
-- `prodex audit` as a local read-only CLI surface for browsing recent append-only audit events
+* a secret-management abstraction for `auth.json` and exported profile bundles
+* a stable live broker snapshot at `GET /__prodex/runtime/metrics`
+* a Prometheus scrape target at `GET /__prodex/runtime/metrics/prometheus`
+* `prodex info` and `prodex doctor --runtime --json` surfacing live broker metrics targets and the selected secret backend
+* append-only audit logging for profile selection, rotation decisions, and admin-facing state changes
+* `prodex audit` as a local read-only CLI surface for browsing recent audit events
 
 Current limitations:
 
-- local `auth.json` remains the compatibility source of truth for current Codex flows even when a non-file backend is selected
-- there is no keychain, Vault, or KMS-backed secret backend implementation yet
-- audit logs follow the resolved runtime log directory by default, or `PRODEX_AUDIT_LOG_DIR` when set
-- there is no central control plane, RBAC, SSO, or SCIM
-- `prodex doctor --runtime --json` is operationally useful, but it is not a full observability stack
-- the repo still assumes a per-host profile pool and local state ownership
-- runtime-store modularization is still in progress, so persistence and audit/event handling remain implementation details rather than a public API
+* local `auth.json` remains the compatibility source of truth for current Codex flows even when a non-file backend is selected
+* there is no keychain, Vault, or KMS-backed secret backend implementation yet
+* audit logs follow the resolved runtime log directory by default, or `PRODEX_AUDIT_LOG_DIR` when set
+* there is no central control plane, RBAC, SSO, or SCIM
+* `prodex doctor --runtime --json` is useful operationally, but it is not a full observability stack
+* the repo still assumes a per-host profile pool and local state ownership
+* runtime-store modularization is still in progress, so persistence and audit/event handling remain implementation details rather than a public API
 
 ## Notes
 
-* Managed profiles share persisted Codex state through Prodex-owned shared storage.
-* `prodex quota --all` refreshes live by default.
-* Use `--once` if you only want a one-shot snapshot.
+* Managed profiles share persisted Codex state through Prodex-owned shared storage
+* `prodex quota --all` refreshes live by default
+* Use `--once` if you only want a one-shot snapshot
 
 ## Learn More
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@christiandoxa/prodex",
-  "version": "0.2.131",
+  "version": "0.2.133",
   "description": "Safe multi-account auto-rotate for Codex CLI with isolated CODEX_HOME profiles",
   "license": "MIT",
   "bin": {
@@ -16,12 +16,12 @@
     "@openai/codex": "^0.118.0"
   },
   "optionalDependencies": {
-    "@christiandoxa/prodex-linux-x64": "0.2.131",
-    "@christiandoxa/prodex-linux-arm64": "0.2.131",
-    "@christiandoxa/prodex-darwin-x64": "0.2.131",
-    "@christiandoxa/prodex-darwin-arm64": "0.2.131",
-    "@christiandoxa/prodex-win32-x64": "0.2.131",
-    "@christiandoxa/prodex-win32-arm64": "0.2.131"
+    "@christiandoxa/prodex-linux-x64": "0.2.133",
+    "@christiandoxa/prodex-linux-arm64": "0.2.133",
+    "@christiandoxa/prodex-darwin-x64": "0.2.133",
+    "@christiandoxa/prodex-darwin-arm64": "0.2.133",
+    "@christiandoxa/prodex-win32-x64": "0.2.133",
+    "@christiandoxa/prodex-win32-arm64": "0.2.133"
   },
   "engines": {
     "node": ">=18"