agent-platform release v4.137.0

Added

  • A codex Harness entry and its egress origins, per installation, off by default (giantswarm/giantswarm#38552). A kagent.harnesses entry takes runtime: codex: the kagent chart renders a Harness on its codex-harness image at the published digest, with the entry’s own name, snapshot location and env and no limits, beside a claude one. The entry’s origins, the installation’s forge and git hosts, go under agent-manager.harness.egress.<Harness name>: agent-manager writes them into a codex agent’s spec.egress, the Substrate egress gate refuses every other origin with a 403, and kagent adds the model destination itself. kagent refuses a share of a Session on a codex Harness, as on every coding Harness. Nothing renders without the values. values.yaml shows the entry, ci/test-coding-agents-values.yaml carries a codex entry beside the claude one with both egress lists, and make verify-kagent-harness and make verify-components-charts assert the forwarded entries, the codex Harness at the chart’s codex-harness digest against the pinned Harness CRD, and agent-manager’s egress map with an entry for every coding Harness.

Changed

  • components.kagent.versionRange and components.kagent-crds.versionRange are >=1.13.0 <1.14.0 (were >=1.12.0 <1.13.0), and the customer BOM pins kagent 1.13.0: a harnesses[] entry runs the codex runtime (giantswarm/kagent-upstream#606). The kagent chart publishes the codex-harness image and stamps its digest into runtimeImages.codexHarness, and a harnesses[] entry takes runtime: codex; the 1.12 chart refused it. The codex runtime reports a turn’s usage on its final task status (giantswarm/kagent-upstream#610). The release also publishes the omp-harness image, which no harnesses[] runtime selects yet. Same upstream pin, no CRD, API or persisted-format change: Substrate stays on 1.11.4, and every conversation carries over (UPGRADE.md).