v0.37.0

Release v0.37.0

v0.36.0

pohunek v0.36.0 compatibility notes

• STORE_SCHEMA_VERSION 10 -> 11 (crates/daemon/src/store/schema.rs:39): the daemon migrates metadata.jsonl on first start and keeps the original as metadata.jsonl.pre-schema-<old>; keep that backup until the new daemon has run correctly. The migration is one-way: an older daemon refuses a schema-11 store (StoreSchemaError), so a rollback to 0.35.x must restore the backup (see the section "Roll back after a completed 0.36 upgrade" in docs/knowledge/runbooks/update-after-release.md, #1549).
• Worker protocol CURRENT_VERSION 7 -> 8 and PREVIOUS_VERSION 6 -> 7 (crates/worker-protocol/src/version.rs:18,21): the live-worker window is now 7..=8. A worker still running protocol 6 (started by a 0.34.x daemon) is not adopted; pohunek service check reports worker_protocol_incompatible and the upgrade refuses without --accept-runtime-loss. Run pohunek service check before upgrading.
• EXPECTED_INTEGRATION_VERSION 14 -> 15 (crates/protocol/src/integration.rs:76): the managed hooks changed (UserPromptSubmit hook, hook report retry). pohunek service upgrade reinstalls the hooks of every listed config home and reports each as installed, failed or gap; for a gap, or a home that had no hooks before, run pohunek integration doctor --all-profiles (or --profile <name>) to reinstall them.
• service.toml schema_version 6 -> 7 (crates/service-config/src/lib.rs, SCHEMA_VERSION): the installer migrates the file on upgrade and a normal load accepts only 7; unknown keys are preserved. An older version's pohunek service refuses a schema-7 file, so a rollback restores the pre-upgrade service.toml (same runbook section, "Roll back after a completed 0.36 upgrade").
• Runtime package pins: Claude package 1.0.2 -> 1.1.0 (verified against Claude Code 2.1.309, minimum stays 2.1.289), Codex package 1.1.1 -> 1.3.0 (verified against Codex 0.164.0, minimum stays 0.160.0), Pi package 1.0.3 -> 1.0.4 (verified against Pi 1.4.0, range 1.0.0 to below 2.0.0), Hermes package 1.0.1 -> 1.0.3; pohunek service upgrade installs the new packages and pins every host profile to them, so a session stopped on an older package digest resumes through the new package.
• PROTOCOL_VERSION (4), MIN_PROTOCOL_VERSION (3) and WORKER_JOURNAL_SCHEMA_VERSION (4) are unchanged.

v0.35.2

Pohunek v0.35.2

v0.35.2 is a patch release for hosts that updated an agent CLI after upgrading to v0.35.1. In v0.35.1 each official runtime package accepted one narrow range of its agent CLI. A host that auto-updated Codex to codex-cli 0.162.1 therefore had every Codex launch, resume and profile refused with agent_runtime_unsupported. The upgrade notes are relative to v0.35.1.

Highlights

Official runtime packages accept every release up to the next major (#1195). Each package now accepts its agent CLI from the verified minimum up to the next major release:

Package	Accepted releases	Package version
Codex	[0.160.0, 1.0.0)	1.1.1
Claude Code	[2.1.289, 3.0.0)	1.0.2
Hermes	[0.20.0, 1.0.0)	1.0.1
Pi	[1.0.0, 2.0.0)	1.0.3

The minimum stays the tested release (Pi was verified on 1.0.2). Releases above the verified one are accepted by policy and have not been verified. The Hermes integration (pohunek integration install|update|doctor --agent hermes, and setup) reads hermes --version through the selected Hermes package's version check. It therefore accepts exactly the releases a Hermes launch accepts, instead of one exact banner.

Clearer version diagnostics (#1195). A refused launch, resume or fork, and the upgrade preflight, still use the code agent_runtime_unsupported. The message now says which of two cases applies, with a recover hint:

• a release outside the range: the message names the parsed release and the supported [min, below);
• output that does not match the runtime's declared format.

pohunek doctor reports the same in its profile and optional-runtime checks. Probe output is never echoed. A failing or timed-out probe keeps the generic message.

Pinned profiles and stopped sessions move to the newer package (#1199). In v0.35.1, profiles and stopped sessions stayed on the exact package digest they were pinned to, together with that package's old range.

• pohunek service upgrade repins every host profile that is pinned to an older version of the release's official package. The plan lists it as repin, and the report lists it as repinned, with both versions and digests. A pinned profile it does not move is listed as kept with a reason, and never refuses the plan. The reasons are a newer version, a non-official package, another package, or an unknown version.

• A stopped session launched from an official package resumes and forks through a strictly newer, selected official version of the same package, when all of these hold:

  • both package records are official;
  • the newer version keeps the integration, the native reference check and the launch the session froze;
  • for a session launched from a profile, that profile pins the newer version.

  The relaunch records the newer digest. The upgrade preflight reports such a session as adoptable with the code adoptable_by_newer_package. Any other session stays on its exact digest, including a stopped session whose profile the upgrade repinned but which the newer version does not adopt; it still resumes from its frozen digest. A live session is never moved.

• pohunek plugin update refuses an official archive older than the selected official version with plugin_update_downgrade, naming both versions, before anything is written. It also refuses a version that cannot be ordered against the selected one (plugin_update_version_unordered). An archive counts as official by its catalog, or when the registry records its digest as official. pohunek plugin select stays the explicit rollback.

• When the selected official package is newer than the release's own, the upgrade plan says that the upgrade re-selects the release's version.

Upgrade and compatibility

• No compatibility constant changed between v0.35.1 and v0.35.2: the store schema, protocol window, worker protocol window, worker journal schema and integration asset version are all the same. Running pohunek service upgrade from v0.35.1 is a daemon swap. Live sessions keep running on their workers.
• Run pohunek service check first. It lists the profiles the upgrade repins or keeps, the stopped sessions that move to the newer package, and whether the upgrade re-selects the release's package over a newer one.
• pohunek service upgrade installs the new Claude Code, Codex and Hermes package versions from the release's runtime/ directory, selects them, and repins profiles pinned to their v0.35.1 packages. Stopped sessions launched on v0.35.1, including Codex sessions refused since a Codex update, resume through the new package once their profile is repinned.
• service upgrade does not update the Pi package (#1222). On a host that uses Pi, run from the extracted release archive pohunek plugin update pohunek.runtime.pi runtime/packages/pi.tar.zst --catalog runtime/runtime-catalog.json --yes, then pohunek plugin profile migrate <name> --yes for each Pi profile. Move a profile pinned to a non-official package, or to a newer version, the same way with plugin profile migrate.
• "Official" means a package record from a catalog that the host's trust anchor verified. Which root or key authorized each record is not recorded yet (#1200).

Known issues

• Known issue (#1196): a profile whose program is a wrapper, for example direnv exec <dir> codex ... or a bridge script, has its version probed as <program> --version without the profile's args. The wrapper must print the agent's own version line, for example codex-cli X.Y.Z or X.Y.Z (Claude Code). Otherwise launch and resume fail with agent_runtime_unsupported, which now reports output that does not match the runtime's declared format. Such profiles worked on 0.34 because the built-in runtimes had no version probe.
• Known issue (#1197): docs/knowledge/runbooks/update-after-release.md says that pohunek service upgrade never rewrites managed hook assets. It does reinstall the integrations it lists. Run pohunek integration doctor --all-profiles after the upgrade for any home it reports as a gap.
• Known issue (#1198): when an upgrade or rollback is refused for sessions at risk, the message says "N live session(s)". The count includes stopped sessions that keep native resume. pohunek service check lists live and stopped sessions separately.
• Known issue (#1194): on macOS, the first agent hook after the first start of the /usr/bin/python3 shim for a user can outlast the agent's 10 s hook timeout. This happens for a new account, or right after an Xcode or Command Line Tools update. That session then has no native reference, so it cannot be resumed or forked. Running python3 -c pass once before starting the first session avoids it.

v0.35.1

Pohunek v0.35.1

v0.35.0 was tagged but never published: its macOS release smoke failed (#1192). v0.35.1 is therefore the first published 0.35 release, and it contains everything listed below. The upgrade notes are relative to v0.34.2, the last published release.

Highlights

Official runtime packages. Claude Code, Codex and Hermes now run only from their official runtime packages. The shell is the only runtime built into the daemon. The daemon archives ship the packages together with a signed catalog. On a host without a runtime's package, a bare launch of that runtime fails with agent_profile_not_found, and the hint names the install command. Package archives use a new encoding (ruzstd 0.9.1, which fixes RUSTSEC-2026-0344). This release refuses archives built for 0.34.x, and 0.34.x refuses archives built for this release. Packages that are already installed keep working across the upgrade.

Single-step upgrade. pohunek service upgrade moves a host from the built-in Claude Code and Codex runtimes to the official packages in one run (#1011). It does the following:

• installs the packages from the release's runtime/ directory;
• pins every host profile to them;
• adopts the live sessions;
• reinstalls the hooks;
• updates the plugin of each marked Hermes home with the hermes on the daemon job's PATH (#1147).

Stopped sessions stay resumable and relaunch from the package. --accept-runtime-loss is needed only for a session the new daemon cannot adopt.

One-step setup. Bare pohunek setup sets up a host (#1013). It installs the service from this release when none is installed and plans the official packages for the runtimes the host has. It previews every change and gap and asks once. Then it installs the packages, pins the profiles, installs the hooks and writes any missing config files. Other options:

• pohunek setup --dry-run prints the plan and changes nothing.
• --yes applies the plan unattended.
• Run from an extracted release archive, setup verifies the archive first.

Setup never upgrades an installed service of another version. Run pohunek service upgrade for that.

macOS on Apple Silicon. The compatibility matrix declares aarch64-apple-darwin rows for Claude Code, Codex, Hermes and Pi. The Apple Silicon daemon archive carries these packages and their attestations next to the signed catalog (#929). On macOS, a session whose agent printed its output and exited right after launch no longer ends with empty output (#1054). On macOS 27, the runtime cleanup decides processes whose environment the kernel withholds by their fork lineage and kernel coalitions. Unrelated system processes therefore no longer leave a session removal unconfirmed (#795, #821).
Notable fixes

• An attached terminal no longer freezes when its own input is larger than the program reads, for example a large paste. Output keeps flowing while that input is pending (#1021).
• session new waits for the daemon's bounded create, including slow pre-create and post-create hooks. It no longer fails with request_timeout after 5 seconds for a session the daemon then created. This changes the default response deadline of session.new in the Rust and TypeScript SDKs (#1014). If the request still times out, the hint explains how to find the session by a --meta key before retrying.
• Initial input is written only after Claude Code or Hermes renders its idle prompt, so the first prompt is no longer lost while the agent starts (#844, #1094). A session.input write the agent does not read fails with session_input_stalled after a configurable bound instead of hanging (#867).
• pohunek session stop no longer fails with timed out waiting for managed process exit when the killed agent is reaped only shortly after the stop grace (#1137).
• After a daemon restart, including every upgrade, a session's first notifications are no longer suppressed by records from before the restart (#1129). pohunek notifications list pages through a long history instead of failing with a framing error (#854).
• Each session gets a private TMPDIR, so concurrent agents no longer overwrite each other's temporary files (#845). Daemon startup deletes the orphaned ones (#1063).
• A session whose working directory no longer exists fails with session_cwd_missing instead of starting the agent in $HOME (#984).
• A lost runtime whose last processes ended during the cleanup is confirmed clean, so its removal is no longer refused (#989).
• pohunek host discover creates its cache directories as 0700, so the daemon no longer refuses worker starts over a 0755 directory (#962).
• A background process that a lifecycle hook started with the hook's stderr survives a daemon restart, instead of dying of SIGPIPE on its next stderr write. A restart while the hook runs, or within two seconds after it ends, still has that effect (#1046).
• The upgrade preflight runs the native reference check that resume runs (#1065). A stopped session whose conversation is already gone from its store is already_not_resumable, so pohunek service upgrade no longer requires --accept-runtime-loss for it. This covers sessions pinned to a package digest, and sessions of a 0.34.0 to 0.34.2 store that the upgrade adopts into the official package. The preflight reads store variables such as CLAUDE_CONFIG_DIR as the daemon job gets them from the service manager. When those variables cannot be read and stopped sessions exist, an upgrade or rollback is refused with service_manager_variables_unread unless --accept-runtime-loss is given; service check only warns. service upgrade and service check take --preflight-budget <SECONDS> (1 to 300, default 20), which bounds the preflight's version probes and reference checks.

Also new:

• workflow plugins, under pohunek workflow, with actions, event reactions, scheduled jobs and services (#148, #325, #326);
• turn waits, through pohunek session wait and session.wait_turn, for agents that manage other sessions (#858);
• pohunek assistant --request-stdin (#769).

Upgrade and compatibility

• STORE_SCHEMA_VERSION: persisted daemon metadata moves from schema 5 (v0.34.x) to 10. Run pohunek service check before upgrading. At startup the daemon backs up a readable older store and migrates it, and every step from 5 to 10 only stamps the new version. After the upgrade a v0.34.x daemon refuses the schema-10 store, so going back to an older release is not supported.
• CURRENT_VERSION: the worker protocol is now version 7, which adds bounded PTY input and a typed refusal for a missing working directory. Upgrade with pohunek service upgrade. Sessions launched or resumed after the upgrade run a version-7 worker.
• PREVIOUS_VERSION: the daemon still accepts version-6 workers, which v0.32.0 through v0.34.2 started. Their live sessions keep running across the daemon swap, but their input writes stay unbounded until the sessions are relaunched. Older workers are outside the window. Run pohunek service check first: it reports any session the upgrade would not adopt.
• EXPECTED_INTEGRATION_VERSION: managed agent integration assets move from version 11 to 14. pohunek service upgrade reinstalls the integrations it lists and the Hermes homes that carry the pohunek marker, and reports each result. For a home the upgrade reports as a gap, or after an install that did not go through service upgrade, run pohunek integration install --agent <agent>.

Known issues

• Known issue (#1194): on macOS, the first agent hook after the first start of the /usr/bin/python3 shim for a user (a new account, or right after an Xcode or Command Line Tools update) can outlast the agent's 10 s hook timeout. That session then has no native reference, so it cannot be resumed or forked. Running python3 -c pass once before starting the first session avoids it.
• Known issue (#1195): each official runtime package accepts only a narrow range of its agent CLI: Codex 0.160.x, Claude Code 2.1.289 up to 2.2.0, Hermes 0.20.0 and Pi 1.0.x. With a newer agent CLI on the host, for example Codex 0.162.1, every session and profile of that runtime is refused with agent_runtime_unsupported, including resume. pohunek doctor reports only an unsupported version. 0.35.2 widens the ranges. Until then, keep the agent CLI inside the range.
• Known issue (#1196): a profile whose program is a wrapper (for example direnv exec ... or a bridge script) is version-probed as <program> --version, without the profile's args. The wrapper must print the agent's own version line (codex-cli X.Y.Z or X.Y.Z (Claude Code)). Otherwise launch and resume fail with agent_runtime_unsupported. Such profiles worked on 0.34 because the built-in runtimes had no version probe.
• Known issue (#1197): docs/knowledge/runbooks/update-after-release.md says that service upgrade never rewrites managed hook assets. In fact it reinstalls the integrations it lists, as these notes say. Run pohunek integration doctor --all-profiles for the homes it reports as a gap.
• Known issue (#1198): an upgrade refused for sessions at risk says "N live session(s)", but the count includes stopped sessions that keep native resume. pohunek service check lists the two groups separately.

v0.34.2

Pohunek v0.34.2

This is the first published release since v0.33.1. The v0.34.0 and v0.34.1 tags published no artifacts because their release workflows stopped before publication.

• STORE_SCHEMA_VERSION: persisted daemon metadata is at schema 5. Run pohunek service check before upgrading; the daemon backs up and migrates readable older stores at startup. A store it cannot migrate is left untouched and prevents startup.
• MIN_PROTOCOL_VERSION: the v4 daemon accepts v3 public-protocol clients through the previous-version adapter. Existing v3 clients remain within the supported window; clients older than v3 need updating.
• EXPECTED_INTEGRATION_VERSION: managed agent integration assets advanced from version 9 to 11. On each daemon host, check integration status and rerun pohunek integration install --agent <agent> for installed agents whose managed assets need updating.

Session recovery follows the verified current native conversation, checks its transcript before resume or fork, and exposes the native target and last file activity. Initial input waits for agent reader readiness with host-configurable bounded timing, including compatibility with previous-release clients.

This release corrects the signing-secret handoff between the release workflow and its reusable evidence workflow. The runtime behavior is unchanged from the unpublished v0.34.1 tag.

v0.33.1

Release v0.33.1

v0.33.0

Release v0.33.0

v0.32.3

Release v0.32.3

v0.32.1

Release v0.32.1

v0.32.0

Incomplete release, use v0.32.1. The Release run for this tag published only the TypeScript SDK tarballs.

• The Linux binaries were not built: the musl legs could not link host binaries (#471).
• The macOS archives were not signed, because signing credentials are not configured.

v0.32.1 carries the same code with the release workflow fixed.