@jc_stack/ez-agents 0.1.0-beta.12 → 0.1.0-beta.18

package/.dockerignore

@@ -21,4 +21,8 @@
 !CONTRIBUTING.md
 !CHANGELOG.md
 !scripts/release-check.mjs
+!scripts/stage-qa.mjs
 !default-plugins.json
+!scripts/trusted-beta.mjs
+!scripts/generate-publish-caller.mjs
+!scripts/smoke-busy-reply.ts

package/.env.example

@@ -11,7 +11,7 @@ EZ_AGENT_WORKSPACE=./agent
 # EZ_PAIRING_TTL_SECONDS=900
 
 # Optional. Default is 300.
-# EZ_EXECUTOR_TIMEOUT_SECONDS=300
+# Agent execution has no wall-clock timeout. Use /stop or schedule cancel.
 
 # CLI Executor adapter. Supported: agy (default), claude, grok, opencode
 # Switch easily with: pnpm run setup <executor-name>
@@ -24,3 +24,18 @@ EZ_EXECUTOR_CLI=agy
 # Optional: OpenRouter API key for OpenCode CLI (Nemotron 3.5 Lightning)
 # OPENROUTER_API_KEY=
 # OPENCODE_MODEL=openrouter/nvidia/nemotron-3.5-lightning
+
+# Interactive Codex CLI context limit; native compaction preserves the session.
+EZ_CODEX_AUTO_COMPACT_TOKENS=64000
+
+# Automatic core/plugin repair mandate. Set in deployment docker.env for Compose.
+# Does not grant GitHub access, merge or publication permissions.
+EZ_REPAIR_ENABLED=true
+
+# Optional PagerDuty incident paging for critical Stocks outages. Put the routing
+# key only in the private relay.env file when running Docker; place the other
+# settings in docker.env so Compose passes them to the relay.
+# PAGERDUTY_ROUTING_KEY=
+# EZ_PAGERDUTY_STOCKS_HEALTH_URL=http://10.97.0.1:3006/health/critical
+# EZ_PAGERDUTY_POLL_SECONDS=30
+# EZ_PAGERDUTY_FAILURE_THRESHOLD=3

package/AGENTS.md

@@ -1,5 +1,12 @@
 # ezenciel-agents — Coding Standards & Architectural Invariants
 
+Ez supports two independent, composable uses: an autonomous Telegram agent and
+workspace-scoped plugins called by your existing local CLI/GUI executor.
+For CLI-only requests, follow [standalone setup](docs/standalone-cli.md): no Telegram
+pairing, relay or host executor is required. The main-first Telegram onboarding
+rules below apply only when installing the autonomous relay. When both are
+requested, keep each workspace's authority and registry explicit.
+
 Installed runtime operation uses Docker Compose. Read
 [Docker setup, state and QA](docs/docker-runtime.md). Docker owns relay/plugin services; the existing host CLI and login are shared
 through one generic transport, with separate agent workspaces and sessions.
@@ -56,17 +63,17 @@ This package will be published as an open-source, lightweight Telegram-to-CLI re
 
 ## 6. Concurrency & Workspace Invariants
 - **1 Writer Job per Workspace:** The agent's Markdown folder (`./agent/`) is its mind. Never run concurrent background processes writing to the same workspace simultaneously.
-- Executor jobs queue sequentially in `RunStore`; the poller remains available for cancellation and incoming messages. There is no separate planner or automatic chat ACK lane.
+- Main-conversation jobs queue sequentially in `RunStore`. Scheduled/background work uses separate task directories and native CLI sessions (up to four alongside chat). Never share a mutable task directory. Delegation decisions and goal persistence belong to the agent/executor; there is no automatic planner or canned chat ACK. Production executor runs have no wall-clock timeout; cancellation is explicit.
 
 ## 7. Fail-Closed Authority (Channel Access ≠ Execution)
-- Incoming messages from unapproved senders must **never** spawn the executor. First DM registers an unapproved pairing request, then stops.
-- Group messages or unknown DMs fail silently.
+- Incoming messages outside the approved owner binding must **never** spawn the executor. A first DM or group message records a pending request only. Explicitly approved owner groups grant owner access to all human members in that exact chat; bots and anonymous posts are ignored.
+- Unapproved group messages from other senders and unknown DMs fail silently. Approved group text uses the existing conversation grant and restricted task runner. Paired-owner group text is discovery routed to the owner's private chat; it grants no group reply authority.
 - Stopping work (`/stop`) must terminate the active worker PID immediately (`SIGTERM`, escalating to `SIGKILL` if unclosed after 3s).
 
 ## 8. Mandatory Adversarial & Negative Tests
 Every pull request modifying authority, execution, or routing must include negative tests:
 1. Unapproved Telegram ID $\rightarrow$ no process spawned.
-2. Group message $\rightarrow$ silent ignore.
+2. Non-owner group message $\rightarrow$ silent ignore; owner group discovery $\rightarrow$ private destination only.
 3. Executor environment check $\rightarrow$ asserts `TELEGRAM_BOT_TOKEN` is `undefined`.
 4. Corrupt JSON in store $\rightarrow$ handled gracefully without process crash.
 5. Injected path traversal in IDs $\rightarrow$ rejected.
@@ -82,3 +89,8 @@ worktree/branch/PR, starting from fetched origin/main. Do not switch or mix work
 another task's checkout. Stage only this task's changes. Keep its worktree through
 review and QA; independent review and green CI precede an authorized merge.
 Never treat task completion as permission to merge or publish.
+Own the complete engineering/release handoff in CONTRIBUTING.md. Once ready,
+proactively request only missing merge/release authority, then ship and verify;
+do not leave the maintainer to discover ready drafts or operate the release.
+
+- In channel-backend mode, the application owns native sessions and actions. Forward normalized inputs with stable run IDs, recover only by idempotent backend submission, and deliver replies through the existing outbox. Never launch a fallback CLI or pass relay credentials into an executor.

package/CHANGELOG.md

@@ -1,5 +1,76 @@
 # Changelog
 
+## 0.1.0-beta.18
+
+- Await complete relay cleanup after fatal Telegram polling errors and preserve the primary failure.
+- Refresh package-owned shared guidance in owner worker prompts, including resumed and scheduled work, while preserving personal workspace instructions and restricted worker boundaries.
+- Include the reviewed beta.17 fixes. Earlier immutable unpublished candidates and existing beta acceptance limits remain.
+
+## 0.1.0-beta.17
+
+- Capture executor stderr before asynchronous PID persistence so fast failures retain actionable, redacted diagnostic evidence for agent-owned recovery.
+- Wait for executor cleanup and final run-state writes when stopping the relay, so shutdown does not return while its state is still being written.
+- Include the reviewed beta.16 runtime and catalog corrections. Earlier unpublished candidates remain preserved; existing beta acceptance limits remain.
+
+## 0.1.0-beta.16
+
+- Correct stale plugin-publication claims and link the catalog to live npm/GitHub release records. Agents must verify available versions instead of treating a dated catalog snapshot as a blocker.
+- Include the reviewed beta.15 runtime unchanged. Preserve earlier unpublished candidates and existing beta acceptance limits.
+
+## 0.1.0-beta.15
+
+- Include current reviewed model defaults, reply/status fixes, shared Library services and CPU limits, and the corrected main-CI publisher validation.
+- Testing beta; previously documented live-provider and fresh-host acceptance limits remain.
+
+## 0.1.0-beta.14
+
+- Preserve agent-specific scheduled authentication and model catalogs; show native
+  Codex defaults in status, and support explicitly approved group ownership.
+- Keep owner chat responsive during shared work with restricted reply sessions.
+  Capture redacted failure evidence and support quiet, owner-scoped reviews.
+- Add opt-in shared Docker plugin workers and agent-owned repair instructions.
+- Add optional PagerDuty Stocks monitoring with restart-safe recovery. Activation
+  requires the companion Stocks critical-health endpoint and private routing-key
+  configuration; real trigger/resolve delivery is not yet verified.
+- Publish verified beta artifacts through the shared trusted-publisher workflow.
+
+- Add explicit host-owned shared-workspace access and serialize bindings to the
+  same resolved repository path while retaining isolated task transcripts.
+- Bound interactive Codex context through native compaction and expose
+  content-free launch, execution and delivery timings.
+- Support owner-approved Telegram text groups and ongoing incoming-only grants
+  through restricted task execution; retain exact conversation/account authority.
+- Preserve revocation recovery and uncertain-send receipts. Ongoing WhatsApp
+  grants require the companion WhatsApp beta.13 provider.
+- Fix graceful container shutdown, isolate CI package sources and await RPC
+  fixture cleanup. Make verified release handoff proactive and agent-owned.
+- Beta limits: no group media; live group-recipient and final fresh-host/reboot
+  acceptance remain pending. No new live-delivery or latency claims.
+- Default core and plugin automatic updates to the beta channel; preserve saved
+  stable-only and manual policies.
+
+## 0.1.0-beta.13
+
+- Escalate cancelled plugin clients and report container cleanup failures.
+- List the GitHub CLI plugin in the public catalog.
+- Include standalone CLI, native task runtime and integration discovery updates.
+
+- Support incoming-only reply tasks without an opening message; refresh installed
+  guidance for selective setup, implicit follow-up, and quiet account linking.
+
+- Add owner-approved, single-contact messaging tasks, core-bound sends and notes,
+  fresh restricted Codex execution, revocation/expiry, and durable uncertain sends.
+- Task execution requires audited Codex 0.153.4 and a message-v1 event source.
+  Other external events remain blocked; live provider acceptance is pending.
+
+
+- Add optional per-command exposure declarations and `ez tools exposure` with
+  conservative defaults. Declarations do not grant authority.
+- Block registered external events before owner-runtime execution; keep durable
+  blocked records visible in work status. This disables prior external wakeups
+  until an isolated runner exists. Recheck active paired-owner provenance at
+  the local and host launch boundaries.
+
 ## 0.1.0-beta.12 — self-upgrade beta
 
 - Agent-owned main/plugin upgrades with stable-default policy, queued maintenance,

package/CONTRIBUTING.md

@@ -13,11 +13,15 @@ repository. Public docs describe shipped behavior and explicit limitations.
    Packaging/runtime changes also need the Docker checks in docs/releasing.md.
 5. Open a PR explaining the problem, resulting behavior, verification and limits.
    Include a short sanitized reproduction. State which tests were not run.
-6. A maintainer reviews and merges after CI. Maintainers use PRs too. No CLA,
-   ticket requirement, custom commit format or additional approval committee.
+6. Obtain independent review and required CI, then complete the
+   maintainer-authorized merge. Maintainers use PRs too. No CLA, ticket
+   requirement, custom commit format or additional approval committee.
 
 You are responsible for understanding submitted code, including AI-generated
 code, and having the right to contribute it under this repository's license.
+For unreleased feature testing, follow [local QA](docs/local-qa.md): stage an
+immutable beta candidate and provide a simple PA upgrade instruction and feature
+QA flow. A public release is not required for this handoff.
 Do not upload conversation dumps, credentials, QR codes or customer records.
 Installation authority alone does not authorize messaging another person.
 Use synthetic providers for routine tests; live tests need a dedicated account
@@ -45,8 +49,8 @@ docs/plugin-contributions.md.
   Branch from an unmerged feature only when the dependency is intentional and
   documented; do not quietly include it in an unrelated PR.
 - Open a draft PR when the change is reviewable. Report its scope, exact commit,
-  validation and remaining QA. A completed coding task can remain a draft;
-  implementation completion does not authorize merge or npm publication.
+  validation and remaining QA. Continue through the release handoff below;
+  implementation completion alone does not authorize publication.
 - Before merge, obtain an independent human or agent review of the final diff.
   The implementer's self-check and passing CI are not independent review.
   Reviewers inspect correctness, architecture, state/permissions and negative
@@ -63,6 +67,31 @@ docs/plugin-contributions.md.
   the clean task worktree after valuable work is preserved; never force cleanup.
   Delete its branch only after confirming merge or authorized abandonment.
 
+## Agent-owned release handoff
+
+The agent owns the engineering work through shipping: implement, run proportional
+checks, obtain independent review, repair findings, verify the packed artifact,
+and prepare the release. Reuse valid final-commit evidence; repeat checks when
+changes or failures invalidate it. Do not leave a ready feature silently in draft
+or ask the maintainer to run commands, coordinate reviewers, or operate CI.
+
+The maintainer's request is authorization for the requested work and its normal
+implementation steps. Do not ask them to approve the same work again. Once the
+applicable gates pass, execute the requested merge/release and report the packages,
+versions, channel, verification and material limits. Batch related packages in
+dependency order. Prepare the reviewed commits, artifacts and checksums before
+shipping. A request to merge does not silently expand to publication or changing
+a private package's visibility; a request to release already authorizes release.
+If shipping was not requested, report readiness and the next step without treating
+every completed feature as permission to publish.
+
+Complete the authorized merge, publication and rollout using
+docs/releasing.md, then verify registry metadata, downloaded artifact and the
+installed runtime. Report the outcome. Escalate only a product decision, missing
+credential/2FA, failed gate that cannot be repaired in scope, or material scope
+change. Human attention belongs on product intent;
+the agent operates the technical workflow.
+
 Example, substituting a unique task name and an absolute external directory:
 
 ```sh
@@ -71,3 +100,7 @@ git worktree list
 git fetch origin
 git worktree add -b feat/task-name /absolute/worktrees/task-name origin/main
 ```
+
+Beta publishing workflow changes follow [trusted publishing](docs/trusted-publishing.md).
+Validate wrong source, repository, package, version and artifact inputs with
+negative tests. Never dispatch publication to test authentication.

package/README.md

@@ -1,12 +1,104 @@
-# ezenciel-agents
+# Ez — AI assistants for small businesses
 
-Telegram `/status` shows the running relay and host
-versions plus installed plugin versions. The agent's `ez status` adds verified
-plugin runtime states and upgrade job receipts. See [status and upgrades](docs/upgrades.md).
+**A lightweight, open-source foundation for persistent AI assistants, powered by
+existing AI harnesses.** Give an assistant a purpose, a workspace and tools for
+your business, then work with it through chat.
+
+Ez is for owners of shops, studios and small teams who want help doing everyday
+work: preparing quotes, maintaining business records, researching decisions or
+following up on an agreed task. Each assistant has its own working context and
+responsibilities. The tools and permissions you configure determine what it can
+do.
+
+An AI harness is the client that lets a model reason, use tools and carry out
+work. Ez uses your chosen host CLI and its existing login. The harness does the
+reasoning; Ez connects it to a persistent workspace, messaging, plugins and
+explicit authority boundaries. Telegram is the current owner interface.
+
+## What makes an Ez assistant
+
+| Part | What it contributes |
+|---|---|
+| **Workspace** | Markdown instructions, business context and working files that persist across conversations and changes of AI. |
+| **Harness** | The existing AI client that plans, chooses tools and executes work. See [AI selection](docs/architecture/ai-selection.md). |
+| **Authority** | A verified owner and explicit limits on delegated work. Receiving a message or installing a tool does not grant permission to act. |
+| **Plugins** | Separately maintained tools and connections, with instructions the agent can discover and use. Provider authentication and receipts belong to the plugin. |
+| **Messaging and continuity** | A way to reach the assistant, return results and continue work in its own environment. |
+
+The design starts with one assistant, one mind and clear responsibilities.
+Business instructions live in the workspace; reusable capabilities live in tools
+and plugins. The agent decides how to do the work using those instructions and
+the capabilities available to it.
+
+Use the harness's native capabilities when they meet the need. Add a standalone
+plugin when a missing integration earns the maintenance. Ez keeps the surrounding
+runtime small, so your files, tools and business knowledge remain useful as AI
+clients improve.
+
+## Plugin catalog
+
+Browse the [available plugins](docs/plugin-catalog.md) for capabilities you can
+add to your assistant. The first released plugin is
+[WhatsApp](https://github.com/jdorado/ez-whatsapp), which connects an existing
+WhatsApp account. Ask your working Ez assistant to set it up in Telegram.
+
+## Start with one useful job
+
+Ez supports two independent, composable uses: an autonomous Telegram agent and
+workspace-scoped plugins called by your existing local CLI/GUI executor.
+For CLI-only requests, follow [standalone setup](docs/standalone-cli.md): no Telegram
+pairing, relay or host executor is required. The main-first Telegram onboarding
+rules below apply only when installing the autonomous relay. When both are
+requested, keep each workspace's authority and registry explicit.
+
+Ask an AI agent with computer access to install Ez for a concrete purpose:
+
+> Install Ez from https://github.com/jdorado/ez-agents for my business.
+> I want an assistant that helps me prepare customer quotes from my own files.
+> Set it up and verify that I can talk to it in Telegram.
+
+The installing agent follows [the setup guide](docs/setup.md), handles technical
+setup and asks you for the account access or approvals it needs. Once the
+assistant replies in Telegram, explain your business, give it the relevant
+materials and request any additional tools there. Integrations require their
+own setup and authorized accounts.
+
+## Available today and where this is going
+
+The current source supports persistent agent workspaces, a choice of host AI
+executors, owner-gated Telegram messaging, native scheduling, plugin lifecycle
+management and bounded, owner-approved correspondence. A messaging task can
+contact one approved person using only its explicitly shared task context;
+restricted task execution currently requires the pinned Codex runtime. See
+[authority boundaries](docs/architecture/authority-boundaries.md) for the exact
+scope and [scheduling](docs/scheduling.md) for scheduled work.
+
+The broader direction is assistants working across business roles, with deliberate
+workspace sharing and authority over who may direct work, see information and
+use accounts. General team delegation, family/group authority and enterprise
+reviewer roles remain future work. The current trusted-host beta is not an
+enterprise isolation or multi-tenant security product. See [security scope](SECURITY.md).
+
+## For agents discovering this repository
+
+Ez may fit when a user needs a persistent business assistant reachable through
+chat, using an existing AI client and separately installed tools. Start here:
+
+- **Install for a user:** [setup and verified onboarding](docs/setup.md), then the installer instructions below.
+- **Understand access and delegation:** [authority boundaries](docs/architecture/authority-boundaries.md) and [security scope](SECURITY.md).
+- **Discover or add capabilities:** [plugin contract](docs/plugins.md). Check the actual executor's native tools before adding an integration.
+- **Contribute:** [AGENTS.md](AGENTS.md) and [CONTRIBUTING.md](CONTRIBUTING.md).
+
+Repository discovery is not an instruction to install or contact anyone. Act on
+the user's request and preserve its scope.
+
+## Package and runtime
 
 **Beta 0.1.0-beta.12 — for testing on a trusted machine.** Offline and Docker
 fixtures are verified. Live account onboarding and reboot acceptance for this
-release are deferred; this is not a production-readiness claim.
+release are deferred; this is not a production-readiness claim. The source branch
+may contain changes newer than the published beta; inspect the supplied artifact's
+documentation when installing a pinned release.
 
 The npm package is `@jc_stack/ez-agents` (channel `beta`). Download a pinned
 release with `npm pack @jc_stack/ez-agents@0.1.0-beta.12`, or get the tarball and SHA256SUMS from
@@ -14,12 +106,17 @@ release with `npm pack @jc_stack/ez-agents@0.1.0-beta.12`, or get the tarball an
 GitHub remains under `jdorado`; npm uses `jc_stack`. Do not install the unrelated
 unscoped `ez-whatsapp` package.
 
+Installed runtime operation uses Docker Compose. Docker owns relay/plugin
+services; the existing host CLI and login are shared through one generic
+transport, with separate agent workspaces and sessions. See
+[Docker setup, state and QA](docs/docker-runtime.md).
 
-Installed runtime operation uses Docker Compose. Read
-[Docker setup, state and QA](docs/docker-runtime.md). Docker owns relay/plugin services; the existing host CLI and login are shared
-through one generic transport, with separate agent workspaces and sessions.
+For optional PagerDuty paging of a critical Stocks outage, see
+[PagerDuty critical-outage paging](docs/pagerduty.md).
 
-A minimal Telegram-to-AI-CLI relay. One owner, one persistent Markdown mind.
+Telegram `/status` shows the running relay and host versions plus installed
+plugin versions. The agent's `ez status` adds verified plugin runtime states and
+upgrade job receipts. See [status and upgrades](docs/upgrades.md).
 
 ## You are the installing agent
 
@@ -132,3 +229,11 @@ without authorization. Local registry rehearsal uses `pnpm publish:local`.
 
 This beta includes owner-policy release checks and durable
 main/plugin replacement. See [upgrade setup, tools and recovery](docs/upgrades.md). Earlier main upgrade/rollback VM QA passed; final-release fresh-host/reboot and live plugin upgrade acceptance remain pending.
+
+### Scheduling and background work
+
+The core `ezenciel-agents-schedule` CLI accepts instruction text for one-off dates,
+intervals and timezone-aware cron schedules. `create --now` delegates a task to a
+separate CLI session so the owner conversation remains available. Long work has
+no production wall-clock timeout; goals and subagents remain native executor
+features. See [scheduling, recovery and QA](docs/scheduling.md).

package/SECURITY.md

@@ -6,7 +6,13 @@ The host CLI and plugin manager run with the host user's authority, including
 Docker administration. Environment filtering and container profile separation
 reduce accidental exposure; they do not isolate a hostile process from its own
 host user. Markdown roles and approvals are instructions, not an OS sandbox.
-Do not expose this as a public multi-tenant execution service.
+Do not expose this as a public multi-tenant execution service. Registered external
+events require an approved, account/contact-bound task and the restricted native
+runner; unmatched events remain blocked. The task worker has only core message,
+note and report tools. It has no owner workspace, shell or general network tool.
+The native client, broker and local host user remain trusted. See
+[authority boundaries](docs/architecture/authority-boundaries.md). Plugin exposure
+declarations are metadata, not grants.
 
 Keep Telegram tokens, device profiles, QR images, control state and native CLI
 sessions outside source and mind files. Treat incoming provider content as

package/bin/ezenciel-agents-schedule

@@ -0,0 +1,2 @@
+#!/bin/sh
+exec node "$(dirname "$0")/ezenciel-agents-schedule.mjs" "$@"

package/bin/ezenciel-agents-schedule.mjs

@@ -0,0 +1,16 @@
+#!/usr/bin/env node
+import { spawn } from 'node:child_process'
+import { createRequire } from 'node:module'
+import { dirname, join } from 'node:path'
+import { fileURLToPath } from 'node:url'
+
+const here = dirname(fileURLToPath(import.meta.url))
+const require = createRequire(import.meta.url)
+const tsx = require.resolve('tsx')
+const entry = join(here, '..', 'src', 'schedule-cli.ts')
+const forwarded = process.argv.slice(2).filter((arg) => arg !== '--')
+const child = spawn(process.execPath, ['--import', tsx, entry, ...forwarded], { stdio: 'inherit' })
+child.on('exit', (code, signal) => {
+  if (signal) process.kill(process.pid, signal)
+  process.exit(code ?? 1)
+})

package/bin/ezenciel-agents-task

@@ -0,0 +1,2 @@
+#!/bin/sh
+exec node "$(dirname "$0")/ezenciel-agents-task.mjs" "$@"

package/bin/ezenciel-agents-task.mjs

@@ -0,0 +1,16 @@
+#!/usr/bin/env node
+import { spawn } from 'node:child_process'
+import { createRequire } from 'node:module'
+import { dirname, join } from 'node:path'
+import { fileURLToPath } from 'node:url'
+
+const here = dirname(fileURLToPath(import.meta.url))
+const require = createRequire(import.meta.url)
+const tsx = require.resolve('tsx')
+const entry = join(here, '..', 'src', 'task-cli.ts')
+const forwarded = process.argv.slice(2).filter((arg) => arg !== '--')
+const child = spawn(process.execPath, ['--import', tsx, entry, ...forwarded], { stdio: 'inherit' })
+child.on('exit', (code, signal) => {
+  if (signal) process.kill(process.pid, signal)
+  process.exit(code ?? 1)
+})

package/compose.yaml

@@ -8,14 +8,22 @@ services:
     restart: unless-stopped
     stop_grace_period: 30s
     cap_drop: [ALL]
-    cap_add: [CHOWN, DAC_OVERRIDE, FOWNER, SETUID, SETGID, SETPCAP]
+    # Init must forward shutdown to the privilege-dropped relay. The entrypoint
+    # still removes every capability from the relay and its executor children.
+    cap_add: [CHOWN, DAC_OVERRIDE, FOWNER, SETUID, SETGID, SETPCAP, KILL]
     environment:
+      EZ_REPAIR_ENABLED: ${EZ_REPAIR_ENABLED:-true}
       EZ_AGENT_PURPOSE_FILE: /run/agent-purpose.md
-      EZ_EXECUTOR_TRANSPORT: host
+      EZ_EXECUTOR_TRANSPORT: ${EZ_EXECUTOR_TRANSPORT:-host}
+      EZ_CHANNEL_BACKEND_URL: ${EZ_CHANNEL_BACKEND_URL:-}
       EZ_AGENT_WORKSPACE: ${EZ_AGENT_WORKSPACE:?Set this agent workspace}
       EZ_CONTROL_DIR: ${EZ_CONTROL_DIR:?Set this agent control directory}
       EZ_EXECUTOR_CLI: ${EZ_EXECUTOR_CLI:?Set the host installation CLI}
+      EZ_CODEX_AUTO_COMPACT_TOKENS: ${EZ_CODEX_AUTO_COMPACT_TOKENS:-64000}
       EZ_EXECUTOR_TIMEOUT_SECONDS: ${EZ_EXECUTOR_TIMEOUT_SECONDS:-300}
+      EZ_PAGERDUTY_STOCKS_HEALTH_URL: ${EZ_PAGERDUTY_STOCKS_HEALTH_URL:-}
+      EZ_PAGERDUTY_POLL_SECONDS: ${EZ_PAGERDUTY_POLL_SECONDS:-30}
+      EZ_PAGERDUTY_FAILURE_THRESHOLD: ${EZ_PAGERDUTY_FAILURE_THRESHOLD:-3}
     secrets: [relay_env]
     configs:
       - source: agent_purpose

package/docker/recovery.ts

@@ -2,10 +2,10 @@ import { RunStore } from '../src/runs.js'
 
 // Called only after the deployment's kernel writer lock is held. No worker
 // from a previous container can still own this deployment; PIDs may be reused.
-export const recoverInterruptedRuns = async (controlDir: string) => {
+export const recoverInterruptedRuns = async (controlDir: string, channelBackend = false) => {
   const store = new RunStore(controlDir)
   for (const run of await store.list()) {
     if (run.status === 'running')
-      await store.patch(run.id, { status: 'failed', endedAt: new Date().toISOString() })
+      await store.patch(run.id, { status: channelBackend && !run.pid ? 'queued' : 'failed', endedAt: new Date().toISOString() })
   }
 }

package/docker/run.ts

@@ -21,12 +21,12 @@ try { privateEnv = parseEnv(readFileSync(3, 'utf8')) } catch (error) {
   if ((error as NodeJS.ErrnoException).code !== 'EINVAL' && (error as NodeJS.ErrnoException).code !== 'EBADF') throw error
 } finally { try { closeSync(3) } catch {} }
 for (const [key, value] of Object.entries(privateEnv)) {
-  if (value !== undefined && ['TELEGRAM_BOT_TOKEN', 'GEMINI_API_KEY', 'OPENAI_API_KEY'].includes(key)) process.env[key] = value
+  if (value !== undefined && ['TELEGRAM_BOT_TOKEN', 'GEMINI_API_KEY', 'OPENAI_API_KEY', 'EZ_CHANNEL_BACKEND_TOKEN', 'PAGERDUTY_ROUTING_KEY'].includes(key)) process.env[key] = value
 }
 privateEnv = {}
 const [command = 'start', ...args] = process.argv.slice(2)
 process.argv = [process.argv[0], '', ...args]
-if (['start', 'smoke'].includes(command)) await recoverInterruptedRuns(loadConfig().controlDir)
+if (['start', 'smoke'].includes(command)) await recoverInterruptedRuns(loadConfig().controlDir, Boolean(loadConfig().channelBackendUrl))
 if (command === 'start') {
   const relay = createRelay(loadConfig())
   const heartbeat = '/state/control/heartbeat.json'

package/docs/architecture/ai-selection.md

@@ -35,3 +35,11 @@ model/effort settings (or `models` for the default model). Claude reads user and
 workspace JSON settings; OpenCode reports resolved config. Unknown defaults and
 opaque wrappers remain explicitly “client default”. No credentials are stored,
 no inference runs, no new dependency, and no cross-CLI session transfer.
+
+`/status` resolves the configured model and reasoning effort for the current
+client-default seed from the agent's isolated Codex profile when that metadata
+is available. If the profile has no explicit model, it uses Codex's native
+default-model catalog for display. It displays that snapshot only; setup and
+refresh do not save the fallback, so the seed remains a native client default
+for later conversations. Desktop Codex remains its own opaque client default
+rather than inheriting CLI configuration.