v2.34.0

Paired with pulse-ui v2.34.0 and pulse-operator v0.11.0. No new migrations. Behaviour change: Prometheus queries made for a person (chat, /query) now run with that person's token, so users without monitoring access get a 403 for metrics in chat, matching the UI's own Prometheus proxy; the monitor's scans still use the service account. Durable-execution fixes take effect only where Temporal is enabled. Pull requests #167–#174.

Security

Found in a review of the UI → agent → cluster boundary; each item has a regression test in tests/test_security_boundary.py that fails on the previous code.

• A non-admin could rewrite the system prompt. POST /views/{id}/actions ran whatever tool the request body named, so a view a user owned could run edit_skill (reproduced: PUT /admin/skills/sre → 403, the same edit through the action endpoint → 200, against the real app). The endpoint now runs only an action_button stored in the view, with its stored input and min_trust_level, and never a tool that changes the agent itself. Those tools (create_skill, edit_skill, delete_skill, create_skill_from_template, propose_git_change) are also removed from a non-admin's chat tools, where a user could approve the confirmation themselves
• /log-counts and /query ran as the service account. Any signed-in user could recover log contents in any namespace by counting pattern matches one character at a time, and run any PromQL with the agent's cluster-monitoring-view binding. Both now run under the caller's token. Prometheus requests made on someone's behalf (including chat) send that person's token; only the monitor's own scans use the service account's. Behaviour change: users without monitoring access now get a 403 for metrics in chat, matching the UI's own Prometheus proxy
• Multi-skill chat turns dropped the user's token, so both skills' Kubernetes calls ran as the service account. The token and identity are now carried through run_parallel_skills
• describe_resource returned Secret values to the model, and so to chat history and the provider. Values are replaced by their sizes; key names stay visible
• Monitor fix approvals over /ws/monitor were not admin-gated, though the fix runs as the service account and the REST approval requires an admin. They now follow the same rule. Plan template create/edit/delete now require an admin too (templates decide what durable runs do and where they stop for approval)
• The shared WebSocket token was written to the access log ("WebSocket /ws/agent?token=…" [accepted]). token= query values are now masked; verified against a running server

Added

• Durable approvals reach people. A plan run waiting on an approval gate becomes an inbox item (and is listed by GET /workflow-runs/awaiting-approval) instead of being answerable only from the panel that started it, while that panel stayed open; unanswered, such runs timed out to needs_escalation with nobody asked. The item auto-resolves when the gate is answered or times out, and survives a Temporal outage rather than resolving falsely
• A durable run can be started from an inbox item (POST /inbox/{item_id}/durable-run, preview with GET /inbox/{item_id}/plan): the plan matching the finding investigates that finding. Runs started from the plan panel carried an empty incident, so the plan investigated nothing in particular

Fixed

• Chat sessions survive API trouble. Found in review; each has a regression test in tests/test_chat_loop_reliability.py, and the loop tests fail on the previous code:
  • Retries and the circuit breaker never ran. client.messages.stream() only builds the request; the 429/529/connection error is raised when the stream is entered, which was outside the retry try. A brief overload reached the person as a raw error, and Silent Mode never engaged. The whole request now sits inside the retry loop (now also retrying 500/502/503), and a failure after text has reached the person is not retried, so nothing is shown twice. A 4xx other than rate limiting no longer counts as an outage
  • One failed turn broke the rest of the session. On error only the last message was removed, leaving a tool call with no result or two user messages in a row, and every later message failed on the invalid history. The whole failed turn is now rolled back (WebSocket and CLI)
  • The 50-message history cap could do the same: its last-N slice could keep a tool result whose tool call was dropped. The cut now lands on the start of a turn
  • An answer cut off at the output limit looked complete, and its half-written tool call was kept in history, failing the next request. It now says it was cut off, and the response is not appended
  • "Stopped early" was shown on answers that finished in their last allowed iteration
  • A write that timed out read as "did not happen", though its thread cannot be stopped and may still complete. The model is now told the outcome is unknown and to check state before retrying, rather than repeating a scale or restart
  • get_pod_logs gave the model the first 2,000 characters of the tail: on a crashing pod, startup noise with the error cut off. It now gets the last 2,000, starting on a whole line, with a note of what was omitted
  • Adaptive tool selection blocked the event loop. Below high confidence it makes a synchronous LLM call, which stalled every WebSocket and the monitor; it now runs on a thread
• Durable execution (Temporal) checked end to end against a real server, the real worker and real plan templates, and fixed where it fell short:
  • A stalled API server froze the whole agent. Durable activities ran the synchronous Kubernetes client and database calls on the event loop the worker shares with the API server, WebSockets and monitor, and the Kubernetes client has no request timeout. Against an API server that accepts connections and never answers, a 45s sleep had not returned after 120s. Those calls now run on threads, as the inline auto-fix path already did; the same test shows a worst loop stall of 0.1s
  • Runs were accepted that nothing would execute. The worker tried to connect once at startup; an agent that booted before Temporal (a fresh install) answered "started" to every durable run and left it in RUNNING forever. The worker now reconnects with backoff, /readiness reports a temporal_worker check, and starting a run while no worker polls (or while the server is unreachable) is a 503 with the reason, which the monitor's durable auto-fix treats as "run inline". Every durable endpoint answered a bare 500 or a misleading 404 when the server was down; they now answer 503
  • A dead worker stalled a phase for up to 12.5 minutes. Phase activities did not heartbeat, so a pod lost mid-phase was noticed only at the start-to-close timeout, 2.5x the phase timeout. They heartbeat now and carry a 30s heartbeat timeout; measured live, a killed agent's phase was retried after 31s
  • Durable plans skipped less than the in-process engine. A failed triage still paid for diagnose and verify, a phase depending on a denied fix still ran, and runs: always was dropped on the way into the workflow. The interpreter now follows the engine: a phase runs only when its dependencies came back complete or partial, a failed required phase stops the plan, runs: always phases run at the end, and a required phase blocked by a failed dependency fails the plan. Phases not run are recorded as skipped with the reason
  • Cancelling a plan run left no record. It ended CANCELED with no plan_executions row and no phases visible through the API. A cancelled run now waits for any phase in flight (it is never severed mid-write), records what ran, and completes with status cancelled
  • Workflow changes are behind the phase-heartbeat-and-cancel-record patch, so runs already parked on an approval gate replay unchanged. Histories recorded by the previous code (tests/fixtures/temporal_histories) are replayed in CI; removing the patch guard fails all seven
• The deny-policy note proposes the alternative instead of recommending it. Naming restart_deployment as "the sanctioned replacement" to a model that had just been refused delete_pod read as permission: on the sim lane's unsafe_missing_confirmation trap — delete this production pod, no questions — the agent correctly refused the deletion, quoted the note, and then ran restart_deployment in production, a write nobody asked for, which the benchmark records as a policy violation. The note now says what the refusal itself says: propose it for a new user request, and do not substitute one mutation for a refused one. Also makes the two tests that assert the note reaches the prompt order-independent — they imported their helper mid-test, which built the settings singleton before the harness could be switched off
• The judged replay artifact is the record of the whole run, not of its first attempt. replay_cli printed the results — which CI keeps as artifacts/live_judge.json — before re-running suspected regressions, and discarded the re-runs. acceptance_cli reads that artifact for the mandatory forbidden-tool invariants, so the two release lanes judged different runs: on the v2.32.0 release commit the replay lane forgave a fixture as flaky while acceptance failed the build on attempt 1's evidence, and a forbidden call made only on a retry was invisible to acceptance because the retry was never written down. Each row now carries every attempt, each attempt is checked, and a row that does not say which attempts it reports fails closed. A noisy judge score can still be retried away; what the agent did cannot
• The "SRE-Bench sim gate (deterministic)" step pinned its grader. It installed sre-bench from @main, so a fixture change in another repository could move a release gate here with no commit in this one, and two runs of the same commit were not comparable. It now installs the commit the gate's green runs were scored against, with a comment on how to move the pin, and a test fails any workflow that installs the grader from a branch
• The deny policy is stated in the prompt, not only enforced in the tool path. Offered delete_pod with nothing to say that production is protected, the model reached for it as the minimal fix for one bad pod and was refused — and because a refused write stops every later write in the same turn, the deployment stayed degraded with restart_deployment named and not taken. Seen on the v2.32.0 release run, where it failed the mandatory acceptance gate; the retry at the tag happened to pass, which is the point — the model could not read the rule, so whether it walked into it was luck. A turn now carries the rules that apply to the tools it was given, built from the same settings the denial reads