Code Mower v1.2.1

Code Mower v1.2.1 Release Notes

Code Mower v1.2.1 is a focused reliability release for maintained Claude
release qualification. It preserves the v1.2 supervised-pilot posture and all
existing provider, campaign, gate, and cloud contracts.

Claude qualification timing

The maintained Claude adapter now tells Claude to report each step duration as
a non-negative integer number of seconds, represent measured setup or
serialization outside named checks as an explicit overhead step, and set the
top-level duration to the exact arithmetic sum of the emitted step durations.

The change addresses a failure mode where an otherwise valid qualification
could report an independently measured total that differed from the rounded
step sum. It does not rewrite provider-authored evidence or relax the closed
adoption-result schema. A mismatch still fails closed, and Code Mower still
performs one paid provider invocation with no automatic retry.

Focused regression coverage proves that an inconsistent result is rejected
after exactly one invocation and that exact integer arithmetic is accepted.
A live maintained-adapter canary against v1.2.0 passed on its first attempt:
Claude emitted step durations of 3, 12, and 0 seconds and a matching 15-second
total. The exact PR head also passed Claude merge-authority review, Codex
informational review, Gitar, and the Python 3.12 through 3.14 package matrix.

Install or upgrade

With uv:

uv tool install --python 3.12 --reinstall --refresh-package code-mower code-mower==1.2.1
code-mower --version

With pipx:

CODE_MOWER_PYTHON="$(command -v python3.12)"
PIP_NO_CACHE_DIR=1 pipx install --force --python "$CODE_MOWER_PYTHON" code-mower==1.2.1
code-mower --version

Expected version output: code-mower 1.2.1.

Privacy

The privacy boundary is unchanged. Campaign adapters parse provider output
transiently and persist only validated code_mower.adoptionResult.v1
metadata. Code Mower does not upload source, Jira summaries or descriptions,
issue bodies, comments, attachments, raw diffs, prompts, transcripts, raw
provider output, authentication output, local paths, or secrets.

Code Mower v1.2.0

Code Mower v1.2.0 Release Notes

Code Mower v1.2.0 makes supervised multi-agent orchestration safer and easier
to inspect. It gives Codex, Claude, and Cursor the same Jira authority contract,
prevents two orchestrators from mutating one working copy at the same time,
and makes hosted release qualification reproduce the validated local command
instead of improvising a result.

Install or upgrade the pinned package:

export CODE_MOWER_PYTHON="$(command -v python3.12)"
PIP_NO_CACHE_DIR=1 pipx install --force --python "$CODE_MOWER_PYTHON" code-mower==1.2.0
code-mower --version

Hosted agents and CI boxes can use:

uv tool install --python 3.12 --reinstall --refresh-package code-mower code-mower==1.2.0
code-mower --version

One Orchestrator Per Working Copy

code-mower session start now takes a local, expiring orchestrator lease. A
second mutating session is refused while the first lease is live; expired or
unreadable leases recover automatically. Read-only brief generation does not
take a lease, and every force release or takeover is explicit. Board shows the
active holder and expiry so operators can resolve ownership without guessing.

Shared Jira Authority

Session briefs now give every orchestrator host the same Jira rules. Code
Mower's bounded REST transport is authoritative for queue reads and all
mutations. Atlassian Rovo MCP and IDE integrations remain optional read/context
enrichment. Jira writes still require the guarded tracker mutate or
tracker pr-sync surface, configured write authority, and explicit apply.

Cursor is qualified against this same brief, lease, and controller telemetry
contract used by Codex and Claude. Other recognized hosts remain explicit
handoffs until separately qualified.

Observable Coordination And Qualification

Controller events include the normalized orchestrator provider in local and
metadata-only cloud evidence. Hosted release-campaign dispatches now include
the exact shell-quoted code-mower release qualify command for the bound tag,
package source, context, provider, and executor. Providers must embed the
generated adoption result unchanged, preserving campaign identity and strict
validation.

Verification And Privacy

The release passed the full unit suite, Ruff, compile checks, generated workflow
validation, privacy scanning, release readiness, source-package rehearsal, and
clean package installation. Python 3.12, 3.13, and 3.14 remain supported.

The privacy boundary is unchanged. Source, Jira summaries and descriptions,
issue bodies, comments, attachments, raw diffs, prompts, transcripts, raw
provider output, authentication output, local paths, and secrets are excluded
from Board and cloud uploads. GitHub remains authoritative for pull requests,
checks, and merge gates.

Code Mower v1.1.2

Code Mower v1.1.2 Release Notes

Code Mower v1.1.2 hardens the opt-in Jira Cloud tracker for large projects and
Jira sites whose create-metadata issue-type inventory is unavailable. The
default GitHub-only workflow is unchanged.

Install or upgrade the pinned package:

export CODE_MOWER_PYTHON="$(command -v python3.12)"
PIP_NO_CACHE_DIR=1 pipx install --force --python "$CODE_MOWER_PYTHON" code-mower==1.1.2
code-mower --version

Hosted agents and CI boxes can use:

uv tool install --python 3.12 --reinstall --refresh-package code-mower code-mower==1.1.2
code-mower --version

Large Jira Projects

Enhanced-JQL queue reads now request at most 25 issues per page. The smaller
page stays inside Code Mower's bounded response budget for metadata-rich Jira
projects while preserving the prior queue coverage: 250 issues by default and
1,000 at the hard page limit. Partial queues still cannot authorize dispatch.

Issue-Type Discovery Compatibility

When Jira returns 404 for the create-metadata issue-type inventory, Code Mower
falls back to Jira's project issue-type endpoint and retains only bounded type
IDs and names. The fallback is intentionally narrow: authentication,
authorization, malformed, oversized, and non-404 failures remain visible.
Required create-field metadata also remains fail-closed rather than being
treated as an empty requirement. This fixes issue #831 in PR #832.

Verification And Privacy

The change was exercised against a large Jira Cloud project with read-only
credentials, deterministic offline fixtures, the full unit suite, the privacy
scan, and Python 3.12, 3.13, and 3.14 CI. Claude's merge-authority audit passed
with no findings and Gitar completed successfully.

Jira queue data remains bounded metadata. Source, Jira summaries and
descriptions, comments, attachments, raw diffs, prompts, transcripts, raw
provider output, authentication output, local paths, and secrets are excluded
from Board and cloud uploads. GitHub remains authoritative for pull requests,
checks, and merge gates.

Code Mower v1.1.1

Code Mower v1.1.1 Release Notes

Code Mower v1.1.1 hardens hosted release qualification after v1.1.0. It makes
GitHub authentication, campaign issue binding, and trusted result-author
posture survive the normal dispatch, watch, and retry cycle, and makes failed
remote package installs return bounded, actionable classifications.

Install or upgrade the pinned package:

export CODE_MOWER_PYTHON="$(command -v python3.12)"
PIP_NO_CACHE_DIR=1 pipx install --force --python "$CODE_MOWER_PYTHON" code-mower==1.1.1
code-mower --version

Hosted agents and CI boxes can use:

uv tool install --python 3.12 --reinstall --refresh-package code-mower code-mower==1.1.1
code-mower --version

Authenticated GitHub And Durable Issue Binding

GitHub-comment qualification transports now reuse authenticated gh access
when no configured token environment variable is present. Authentication
probe output and credentials are never printed or stored in campaign state.
Explicit token environment variables retain precedence, and Devin's API
credential handling is unchanged.

Campaigns persist their GitHub issue number and reuse it for dispatch, resume,
watch, retry, and result discovery. An older campaign without an issue can be
bound once; a conflicting later issue is rejected before network writes or
campaign mutation. This fixes issue #817 in PR #824.

Persistent Trusted Result Authors

Campaign creation accepts provider-scoped trusted result-author additions.
Provider names and GitHub logins are normalized and validated, then stored as
immutable campaign posture. Subsequent dispatch and result discovery reuse
that posture without requiring an environment override on every command.
Built-in authors and existing environment additions remain supported.

Trusted-author login values stay out of Board and cloud uploads. Exact result
markers, campaign identity, and author binding still fail closed. This fixes
issue #818 in PR #823; see the safe creation example in
Release Qualification.

Actionable Remote Install Failures

Remote qualification results must include an existing closed failure_reason
when package_install fails. Provider instructions explain the categories
and reserve unknown for failures that cannot be classified. Invalid or
missing reasons are rejected before the remote result counts as evidence.
This fixes issue #819 in PR #822.

Upgrade Qualification And Privacy

The v1.1.1 upgrade campaign starts from v1.1.0 and selects Claude and Codex as
required providers, with Antigravity, Muse, Cursor Cloud Agent, and Devin
informational. Required failures block qualification; informational failures
remain visible. Campaign evidence is recorded on release issue #820.

The closed code_mower.adoptionResult.v1 contract remains authoritative.
Operators inspect code-mower release campaign upload in dry-run mode before
explicitly uploading additive adoption_run metadata to CodeMower.com. Source,
raw diffs, prompts, transcripts, raw provider output, authentication output,
local paths, secrets, and trusted-author login values are excluded.

GitHub remains authoritative for pull requests, checks, and merge gates.
Code Mower remains a supervised-pilot release: qualification demonstrates
operational adoption, not reviewer quality or lane-promotion readiness. The
separately tracked live Jira write canary is outside this patch release.

Code Mower v1.1.0

Code Mower v1.1 Release Notes

Code Mower v1.1.0 adds optional Jira Cloud work tracking to the supervised
development loop. GitHub remains authoritative for pull requests, checks, and
merge gates. Repositories that do not configure a tracker keep the existing
GitHub-only behavior and generated workflows.

Install the pinned package:

export CODE_MOWER_PYTHON="$(command -v python3.12)"
pipx install --python "$CODE_MOWER_PYTHON" code-mower==1.1.0
code-mower --version

Hosted agents and CI boxes can use:

uv tool install --python 3.12 code-mower==1.1.0
code-mower --version

Optional Jira Tracker

The provider-neutral code_mower.trackerWorkItem.v1 contract separates work
tracking from builder, reviewer, and gate policy. Jira Cloud support includes:

• tenant- and project-scoped read-only issue discovery;
• controller queue, lane-status, and Board visibility;
• explicit pull-request association and bounded PR/gate milestones;
• local credential resolution, including macOS Keychain profiles; and
• init, adoption doctor, deterministic offline fixtures, and a live rehearsal
  runbook.

Start with the default dry run:

code-mower init --jira
code-mower doctor --adoption --repo OWNER/REPO
code-mower tracker status --repo OWNER/REPO

See Jira Cloud Setup and
Jira Adoption Rehearsal. Jira writes are disabled
by default. Enabling them in configuration is necessary but not sufficient:
every mutation command still plans by default and requires an explicit
--apply to write.

Guarded Mutations

The closed mutation surface supports only claim, configured lifecycle
transitions, bounded templated comments, and one pull-request remote link. It
does not expose delete, attachment, arbitrary field update, or free-form
comment operations.

Before every write, Code Mower re-reads and validates the issue id, project,
permissions, and applicable transitions. Writes are attempted once; ambiguous
results fail closed instead of retrying into duplicate effects. Stable Jira
properties make supported comment and link operations replay-safe. Planning,
permission probes, and readiness checks report bounded metadata rather than
Jira issue prose.

GitHub Remains Authoritative

Jira can supply work items and receive selected lifecycle milestones, but it
cannot override GitHub pull-request state, Code Mower audit verdicts, required
checks, or the merge gate. A Jira outage degrades Jira-backed queue visibility;
it does not reinterpret GitHub state or permit a merge.

PR-to-Jira synchronization accepts only explicit associations from trusted
GitHub actors. Association and milestone state are transactional so a failed
write is not reported as synchronized.

Provider And Board Fixes

• Antigravity headless audits now use sandbox-compatible working paths while
  preserving their closed verdict contract.
• Board recognizes supervised Muse processes launched through both the stable
  and versioned Muse executables without exposing arguments or private paths.

Release Qualification

The existing release-qualification contract remains available for Jira and
GitHub-only adopters. A single environment can emit the closed
code_mower.adoptionResult.v1 artifact with:

code-mower release qualify \
  --release-tag v1.1.0 \
  --package-spec code-mower==1.1.0 \
  --output adoption-result.json \
  --execute

For several providers, use code-mower release campaign to create, dispatch,
and watch a bounded campaign. Upload remains a separate, explicit operation:
terminal results become additive adoption_run metadata only after a dry-run
preview and operator confirmation.

Privacy Boundary

The v1.1 tracker contract remains metadata-only. Code Mower does not upload or
persist Jira issue summaries, descriptions, comments, attachments, source,
raw diffs, prompts, transcripts, raw provider output, authentication output,
local paths, or secrets. Jira identifiers and bounded lifecycle metadata are
included only where required to coordinate the configured tracker.

Recommended Adoption

1. Install exactly code-mower==1.1.0 and verify the version.
2. Keep the default GitHub tracker unless Jira is actually part of the team's
   operating model.
3. For Jira, run init and adoption doctor read-only before enabling mutations.
4. Exercise the offline Jira rehearsal, then the live read-only rehearsal.
5. Enable writes only after reviewing the closed operation set and required
   Jira permissions.
6. Keep reviewer lanes informational until repository-specific calibration
   satisfies the lane promotion policy.

The release was qualified across Python 3.12, 3.13, and 3.14 with generated
workflow linting, package and privacy checks, GitHub-only adoption rehearsal,
Jira read-only rehearsal, and an author-excluded peer audit. A live Jira write
rehearsal is intentionally not release-blocking unless the owner separately
authorizes a disposable issue.

Code Mower v1.0.15

Code Mower v1.0.15 Release Notes

Code Mower v1.0.15 is a measurement and release-operations reliability
release. Current-state productivity metrics now prefer live GitHub data,
historical Board observations are clearly labeled, provider credentials can
survive restarts through fail-closed profiles, and the metadata-only evidence
contract gains reviewer finding outcomes, normalized productivity windows, and
PR cost coverage.

Install the pinned package:

export CODE_MOWER_PYTHON="$(command -v python3.12)"
pipx install --python "$CODE_MOWER_PYTHON" code-mower==1.0.15
code-mower --version

Hosted agents and CI boxes can use:

uv tool install --python 3.12 code-mower==1.0.15
code-mower --version

Current State Means Current

code-mower productivity report now collects live lane status and uses it for
current open-PR and gate-alert totals. Historical Board snapshots remain part
of trend and quality analysis, but they no longer override an available live
GitHub observation. Text and JSON output identify whether current state came
from live_remote or historical_board, include its observation time, and mark
historical fallback explicitly. Use --offline when that fallback is the
intended source (issue #793, PR #794).

Evidence And Cost Coverage

• The additive reviewer_finding_outcome event records blocker-level
  dispositions such as accepted-and-fixed, false positive, accepted risk, or
  owner decision. Stable opaque identifiers preserve linkage without uploading
  finding prose, source, diffs, transcripts, or file paths (issue #736,
  PR #787).
• Deterministic normalized productivity windows keep cycle, active, queue,
  review, time-to-green, merge, and owner-wait timing separate. Coverage and
  provenance are explicit, missing values remain unavailable rather than zero,
  and the contract makes no causal claim (issue #738, PR #788).
• code-mower cloud pr-outcomes joins builder runs, reviewer-spend evidence,
  and live GitHub metadata into one event per PR. Cost coverage is reported as
  complete, partial, or unknown, with metadata-only missing-cost source ids
  (issue #737, PR #790).

These event additions remain backward-compatible with earlier v0.x and v1.0
uploads. Dashboard consumers can adopt them incrementally.

Restart-Safe Provider Credentials

Provider credentials now use one fail-closed resolver. Ambient environment
variables win, followed by an explicit profile or file, then unambiguous local
profile discovery under ~/.config/code-mower/. Credential files must be mode
0600 or 0400; ambiguous, malformed, or insecure profiles produce bounded
remediation without exposing values or private paths. Hosted Devin is the first
consumer, and doctor reports the same resolution outcome used by campaigns
(issue #785, PR #789).

Release Qualification

A release campaign can record one explicit linked release PR with
--release-pr. Hosted result discovery reads the campaign issue and that exact
PR only, applies identical trusted-author and closed-schema checks on both, and
deduplicates identical evidence. It never searches arbitrary issues or pull
requests, and stored source metadata contains no comment or issue body text
(issue #791, PR #792).

Each provider still returns the closed code_mower.adoptionResult.v1 artifact.
An explicit campaign upload converts terminal results into additive
adoption_run events; result discovery itself performs no upload.

Qualify one provider environment directly when a full campaign is unnecessary:

code-mower release qualify \
  --release-tag v1.0.15 \
  --package-spec code-mower==1.0.15 \
  --output adoption-result.json \
  --execute

Preview a campaign, then apply only after adoption doctor is ready:

code-mower release campaign create \
  --release-tag v1.0.15 \
  --package-spec code-mower==1.0.15 \
  --providers claude,codex,antigravity,muse,cursor_cloud_agent,devin \
  --required-providers claude,codex \
  --repo-slug OWNER/REPO

code-mower doctor --adoption --repo OWNER/REPO
code-mower release campaign dispatch \
  --release-tag v1.0.15 \
  --required-providers claude,codex \
  --release-pr PR_NUMBER \
  --apply \
  --repo-slug OWNER/REPO \
  --issue ISSUE_NUMBER

Preview the closed cloud bundle before any upload:

code-mower release campaign upload --release-tag v1.0.15 --json
code-mower release campaign upload --release-tag v1.0.15 --yes --json

Cloud sharing remains opt-in and dry-run first. No command in this release
uploads source, raw diffs, prompts, transcripts, issue body text, raw provider
output, authentication output, local paths, or secrets.

Recommended Update

For an existing pipx install:

export CODE_MOWER_PYTHON="$(command -v python3.12)"
PIP_NO_CACHE_DIR=1 pipx install --force --python "$CODE_MOWER_PYTHON" code-mower==1.0.15
code-mower --version
code-mower board list

For hosted agents using uv:

uv tool install --python 3.12 --reinstall --refresh-package code-mower code-mower==1.0.15
code-mower --version

Restart any Board still serving an older package. For existing repositories,
review migration setup-drift output in a pull request before applying
generated changes.

Quality And Privacy Proof

Each behavior change landed in its own pull request with focused tests and peer
review. The v1.0.15 release PR runs package CI across Python 3.12, 3.13, and
3.14, release readiness, generated-workflow checks, privacy scanning, and an
author-excluded peer audit before publication.

Code Mower v1.0.14

Code Mower v1.0.14 Release Notes

Code Mower v1.0.14 is a corrective release-qualification patch. Hosted Devin
polling now accepts a valid closed structured result even while the session
still reports an in-progress status, so a finished informational Devin attempt
is no longer recorded as owner-blocked. It preserves the supervised-pilot
operating model, Python 3.12+ requirement, provider posture, and metadata-only
privacy boundary.

Install the pinned package:

export CODE_MOWER_PYTHON="$(command -v python3.12)"
pipx install --python "$CODE_MOWER_PYTHON" code-mower==1.0.14
code-mower --version

Hosted agents and CI boxes can use:

uv tool install --python 3.12 code-mower==1.0.14
code-mower --version

Why This Patch Exists

The hosted Devin lane is informational, but its result was being discarded for
a reason unrelated to the release. Devin can return the requested structured
output while the session still reports running with status detail
waiting_for_user. The previous polling order checked that owner-input detail
before it looked at the payload, so a session that had already produced a valid
code_mower.adoptionResult.v1 result was recorded as owner-blocked and the
campaign asked the owner to answer a session that was effectively done.
Because a published version is immutable, the fix ships as v1.0.14 rather than
as a correction to v1.0.13.

What Is Fixed

• Hosted Devin polling now evaluates snapshots in explicit precedence order:
  terminal API failure statuses first, then waiting_for_approval, then a
  valid structured result, then waiting_for_user owner action, and only then
  the terminal-without-result rejection. A completed Devin session that
  returned its structured result while still reporting running /
  waiting_for_user is therefore accepted as complete (PR #783).
• Release Qualification records this precedence, so
  an operator watching a campaign can tell an accepted late result apart from a
  session that genuinely needs owner input.

What Is Unchanged

Explicit terminal failures still win over any structured output. When the API
reports error or suspended, or a status detail of error,
usage_limit_exceeded, out_of_credits, out_of_quota,
no_quota_allocation, payment_declined, org_usage_limit_exceeded, or
total_session_limit_exceeded, the attempt is still devin_session_failed
and no structured output is read from it.

Approval gates still win over any structured output. A session whose status
detail is waiting_for_approval is still reported as
devin_waiting_for_owner so the owner decides before Code Mower treats
anything as finished. Only ordinary waiting_for_user now loses to a result
that is already present.

Result acceptance is not loosened. A structured payload is still bound to this
campaign's release tag, package identity, qualification context, and the closed
code_mower.adoptionResult.v1 schema; a payload that does not match is still
recorded as hosted_result_rejected rather than accepted. A terminal session
that produced no structured output at all is still rejected the same way.

The rest of the hosted Devin transport is intact: bounded polling with the
one-hour response deadline owned by campaign watch, hosted_response_timeout
when nothing arrives in time, retries only from terminal sessions with bounded
attempt history preserved, and polling outages that leave the paid attempt
running instead of duplicating it.

Devin remains an opt-in paid lane (enabled_by_default: false,
trigger_policy: manual, spend_policy: paid). This release changes no
reviewer authority, no supervised-pilot gate semantics, no provider posture,
and no privacy boundary.

Provider Posture

Codex audit and Claude audit remain the established reviewer lanes with merge
authority; Gitar stays informational corroboration. Hosted Devin remains an
informational reviewer unless repository-specific evidence promotes it under
the lane promotion policy. Release campaigns keep
Claude and Codex required, with Antigravity, Muse, Cursor Cloud Agent, hosted
Devin, and Devin CLI informational.

Run A Qualification Campaign

Qualify one provider environment directly when a full campaign is unnecessary:

code-mower release qualify \
  --release-tag v1.0.14 \
  --package-spec code-mower==1.0.14 \
  --output adoption-result.json \
  --execute

Preview a campaign with established local providers required and experimental or
hosted providers informational:

code-mower release campaign create \
  --release-tag v1.0.14 \
  --package-spec code-mower==1.0.14 \
  --providers claude,codex,antigravity,muse,cursor_cloud_agent,devin \
  --required-providers claude,codex \
  --repo-slug OWNER/REPO

Apply only after the preview and adoption doctor are clean:

code-mower doctor --adoption --repo OWNER/REPO
code-mower release campaign dispatch \
  --release-tag v1.0.14 \
  --required-providers claude,codex \
  --apply \
  --repo-slug OWNER/REPO \
  --issue ISSUE_NUMBER
code-mower release campaign watch --release-tag v1.0.14

A hosted Devin attempt needs --repo-slug OWNER/REPO and its API environment;
--issue is optional for that lane. See
Devin Setup.

Preview the closed cloud bundle, then upload it explicitly:

code-mower release campaign upload --release-tag v1.0.14 --json
code-mower release campaign upload --release-tag v1.0.14 --yes --json

Qualification writes the closed code_mower.adoptionResult.v1 artifact.
Campaign upload converts terminal results into additive adoption_run events.
It does not upload source, raw diffs, prompts, transcripts, issue body text, raw
provider output, authentication output, local paths, or secrets.

Recommended Update

For an existing pipx install:

export CODE_MOWER_PYTHON="$(command -v python3.12)"
PIP_NO_CACHE_DIR=1 pipx install --force --python "$CODE_MOWER_PYTHON" code-mower==1.0.14
code-mower --version
code-mower board list

For hosted agents using uv:

uv tool install --python 3.12 --reinstall --refresh-package code-mower code-mower==1.0.14
code-mower --version

--refresh-package takes a package name as its value, so the first
code-mower is the cache-refresh target and code-mower==1.0.14 is the single
package argument.

Restart a Board that still serves an older package. For existing repositories,
review migration setup-drift output in a pull request before applying any
generated changes.

Quality And Privacy Proof

The implementation PR passed package CI on Python 3.12, 3.13, and 3.14 and an
exact-head peer audit with the author lane excluded. The behavior was found by
a real hosted Devin campaign attempt rather than by review alone.

Cloud sharing remains opt-in and dry-run first. The default release campaign
works locally without a CodeMower.com account.

Code Mower v1.0.13

Code Mower v1.0.13 Release Notes

Code Mower v1.0.13 is a corrective release-qualification patch. Automatic
campaign runtime selection is now sandbox-safe: when CODE_MOWER_PYTHON is not
set, Code Mower prefers a supported versioned Python on PATH outside the user
home before falling back to its own running interpreter. It preserves the
supervised-pilot operating model, Python 3.12+ requirement, provider posture,
and metadata-only privacy boundary.

Install the pinned package:

export CODE_MOWER_PYTHON="$(command -v python3.12)"
pipx install --python "$CODE_MOWER_PYTHON" code-mower==1.0.13
code-mower --version

Hosted agents and CI boxes can use:

uv tool install --python 3.12 code-mower==1.0.13
code-mower --version

Why This Patch Exists

v1.0.12 was published before its real campaign exposed the remaining runtime
selection problem. On a Mac where Code Mower itself is installed with pipx, the
campaign runner's automatic resolution could pick the pipx-contained
interpreter under the user home. Claude's maintained strict macOS sandbox
denies reads under that home tree, so the qualification run failed for a reason
unrelated to the release even though a readable Homebrew Python was on PATH.
Because a published version is immutable, the fix ships as v1.0.13 rather than
as a correction to v1.0.12.

What Is Fixed

• Automatic Python 3.12+ runtime resolution now prefers versioned PATH
  runtimes outside the user home before falling back to Code Mower's running
  interpreter or another home-contained runtime. A pipx- or uv-installed CLI
  therefore hands the provider an interpreter that remains readable inside
  Claude's strict macOS sandbox, and a maintained Claude campaign no longer
  needs CODE_MOWER_PYTHON set by hand (#778, PR #779).
• Hosted environments that have no runtime outside the home are unchanged: a
  home-contained interpreter is still a supported fallback, so the dispatch
  keeps working where the running interpreter is the only supported Python
  (#778, PR #779).

What Is Unchanged

An explicit CODE_MOWER_PYTHON remains authoritative. When it is set, Code
Mower resolves exactly that interpreter and does not substitute a different
one.

The rest of the deterministic runtime contract is intact. The campaign runner
still passes exact --python-bin and --target-runtime arguments so providers
cannot pick an ambient python3, still fails closed with
python_runtime_unavailable and actionable remediation when no supported
runtime exists, and result validators still enforce
runtime_class >= python_3.12.

The macOS Claude sandbox posture is unchanged: sandbox.enabled,
failIfUnavailable, the disabled unsandboxed escape hatch
(allowUnsandboxedCommands: false), the home read/write denials, the closed
package-index domain allowlist, and pip's TLS-verifying legacy (certifi)
certificate path with no inherited pip configuration. See
macOS Claude sandbox certificate path.

The qualification prompt from v1.0.12 is unchanged, including the disposable
workspace wording and the code_mower.adoptionResult.v1 timing contract. The
agent still must not read or modify an existing checkout, home directory,
credential file, or secret-bearing environment variable, and must not print
secrets, tokens, file paths, commands it ran, or raw logs in its final answer.

The closed code_mower.adoptionResult.v1 schema, outcome derivation from step
statuses, the supervised-pilot gate semantics, and the metadata-only upload
boundary are unchanged. Linux Claude runs and every other provider keep their
existing prompt and certificate behavior.

Provider Posture

This release does not change reviewer authority. Codex audit and Claude audit
remain the established reviewer lanes with merge authority; Gitar stays
informational corroboration. Devin remains an opt-in paid lane
(enabled_by_default: false, trigger_policy: manual, spend_policy: paid)
and an informational reviewer unless repository-specific evidence promotes it
under the lane promotion policy.

Run A Qualification Campaign

Qualify one provider environment directly when a full campaign is unnecessary:

code-mower release qualify \
  --release-tag v1.0.13 \
  --package-spec code-mower==1.0.13 \
  --output adoption-result.json \
  --execute

Preview a campaign with established local providers required and experimental or
hosted providers informational:

code-mower release campaign create \
  --release-tag v1.0.13 \
  --package-spec code-mower==1.0.13 \
  --providers claude,codex,antigravity,muse,cursor_cloud_agent,devin \
  --required-providers claude,codex \
  --repo-slug OWNER/REPO

Apply only after the preview and adoption doctor are clean:

code-mower doctor --adoption --repo OWNER/REPO
code-mower release campaign dispatch \
  --release-tag v1.0.13 \
  --required-providers claude,codex \
  --apply \
  --repo-slug OWNER/REPO \
  --issue ISSUE_NUMBER
code-mower release campaign watch --release-tag v1.0.13

A hosted Devin attempt needs --repo-slug OWNER/REPO and its API environment;
--issue is optional for that lane. See
Devin Setup.

Preview the closed cloud bundle, then upload it explicitly:

code-mower release campaign upload --release-tag v1.0.13 --json
code-mower release campaign upload --release-tag v1.0.13 --yes --json

Qualification writes the closed code_mower.adoptionResult.v1 artifact.
Campaign upload converts terminal results into additive adoption_run events.
It does not upload source, raw diffs, prompts, transcripts, issue body text, raw
provider output, authentication output, local paths, or secrets.

Recommended Update

For an existing pipx install:

export CODE_MOWER_PYTHON="$(command -v python3.12)"
PIP_NO_CACHE_DIR=1 pipx install --force --python "$CODE_MOWER_PYTHON" code-mower==1.0.13
code-mower --version
code-mower board list

For hosted agents using uv:

uv tool install --python 3.12 --reinstall --refresh-package code-mower code-mower==1.0.13
code-mower --version

--refresh-package takes a package name as its value, so the first
code-mower is the cache-refresh target and code-mower==1.0.13 is the single
package argument.

Restart a Board that still serves an older package. For existing repositories,
review migration setup-drift output in a pull request before applying any
generated changes.

Quality And Privacy Proof

The implementation PR passed package CI on Python 3.12, 3.13, and 3.14 and an
exact-head peer audit with the author lane excluded. The change was found by a
real macOS Claude release campaign rather than by review alone.

Cloud sharing remains opt-in and dry-run first. The default release campaign
works locally without a CodeMower.com account.

Code Mower v1.0.12

Code Mower v1.0.12 Release Notes

Code Mower v1.0.12 is a corrective release-qualification patch. It completes the
macOS Claude fix that v1.0.11 started: the maintained provider qualification
prompt no longer contradicts the disposable workspace Code Mower already
creates, and it states the result timing contract explicitly. It preserves the
supervised-pilot operating model, Python 3.12+ requirement, provider posture,
and metadata-only privacy boundary.

Install the pinned package:

export CODE_MOWER_PYTHON="$(command -v python3.12)"
pipx install --python "$CODE_MOWER_PYTHON" code-mower==1.0.12
code-mower --version

Hosted agents and CI boxes can use:

uv tool install --python 3.12 code-mower==1.0.12
code-mower --version

Why This Patch Exists

v1.0.11 was published before the final real macOS Claude campaign proof ran.
That proof exposed the remaining prompt ambiguity described below. Because a
published version is immutable, the fix ships as v1.0.12 rather than as a
correction to v1.0.11.

What Is Fixed

• The release-qualification prompt keeps the agent in the disposable workspace
  Code Mower already created. The old wording told the agent to qualify "in a
  disposable environment you create" and to do all work "inside a fresh
  temporary directory", which conflicts with the maintained macOS Claude strict
  sandbox: the allowed workspace is the one Code Mower prepared, so an agent
  that followed the prompt literally could push its work outside the sandbox's
  allowed workspace and fail the run for a reason unrelated to the release. The
  prompt now says the workspace already exists and that the agent must not
  create or change into another temporary directory (#769, PR #775).
• The qualification prompt states the code_mower.adoptionResult.v1 timing
  contract that a result's total elapsed_seconds is the sum of its step
  elapsed_seconds values, within one second for rounding, so a provider does
  not report a total that contradicts its own steps (#769, PR #775).

What Is Unchanged

Every other qualification instruction is intact. The agent still must not read
or modify an existing checkout, home directory, credential file, or
secret-bearing environment variable, and must not print secrets, tokens, file
paths, commands it ran, or raw logs in its final answer.

The macOS Claude sandbox posture from v1.0.11 is unchanged: sandbox.enabled,
failIfUnavailable, the disabled unsandboxed escape hatch
(allowUnsandboxedCommands: false), the home read/write denials, the closed
package-index domain allowlist, and pip's TLS-verifying legacy (certifi)
certificate path with no inherited pip configuration. See
macOS Claude sandbox certificate path.

The closed code_mower.adoptionResult.v1 schema, outcome derivation from step
statuses, the supervised-pilot gate semantics, and the metadata-only upload
boundary are unchanged. Linux Claude runs and every other provider keep their
existing prompt and certificate behavior.

Provider Posture

This release does not change reviewer authority. Codex audit and Claude audit
remain the established reviewer lanes with merge authority; Gitar stays
informational corroboration. Devin remains an opt-in paid lane
(enabled_by_default: false, trigger_policy: manual, spend_policy: paid)
and an informational reviewer unless repository-specific evidence promotes it
under the lane promotion policy.

Run A Qualification Campaign

Qualify one provider environment directly when a full campaign is unnecessary:

code-mower release qualify \
  --release-tag v1.0.12 \
  --package-spec code-mower==1.0.12 \
  --output adoption-result.json \
  --execute

Preview a campaign with established local providers required and experimental or
hosted providers informational:

code-mower release campaign create \
  --release-tag v1.0.12 \
  --package-spec code-mower==1.0.12 \
  --providers claude,codex,antigravity,muse,cursor_cloud_agent,devin \
  --required-providers claude,codex \
  --repo-slug OWNER/REPO

Apply only after the preview and adoption doctor are clean:

code-mower doctor --adoption --repo OWNER/REPO
code-mower release campaign dispatch \
  --release-tag v1.0.12 \
  --required-providers claude,codex \
  --apply \
  --repo-slug OWNER/REPO \
  --issue ISSUE_NUMBER
code-mower release campaign watch --release-tag v1.0.12

A hosted Devin attempt needs --repo-slug OWNER/REPO and its API environment;
--issue is optional for that lane. See
Devin Setup.

Preview the closed cloud bundle, then upload it explicitly:

code-mower release campaign upload --release-tag v1.0.12 --json
code-mower release campaign upload --release-tag v1.0.12 --yes --json

Qualification writes the closed code_mower.adoptionResult.v1 artifact.
Campaign upload converts terminal results into additive adoption_run events.
It does not upload source, raw diffs, prompts, transcripts, issue body text, raw
provider output, authentication output, local paths, or secrets.

Recommended Update

For an existing pipx install:

export CODE_MOWER_PYTHON="$(command -v python3.12)"
PIP_NO_CACHE_DIR=1 pipx install --force --python "$CODE_MOWER_PYTHON" code-mower==1.0.12
code-mower --version
code-mower board list

For hosted agents using uv:

uv tool install --python 3.12 --reinstall --refresh-package code-mower code-mower==1.0.12
code-mower --version

--refresh-package takes a package name as its value, so the first
code-mower is the cache-refresh target and code-mower==1.0.12 is the single
package argument.

Restart a Board that still serves an older package. For existing repositories,
review migration setup-drift output in a pull request before applying any
generated changes.

Quality And Privacy Proof

The implementation PR passed package CI on Python 3.12, 3.13, and 3.14 and an
exact-head peer audit with the author lane excluded. The change was found by a
real macOS Claude release campaign rather than by review alone.

Cloud sharing remains opt-in and dry-run first. The default release campaign
works locally without a CodeMower.com account.

Code Mower v1.0.11

Code Mower v1.0.11 Release Notes

Code Mower v1.0.11 is a release-qualification patch. It moves canonical hosted
Devin campaigns onto the bounded, pollable Devin Sessions API v3 transport, and
it lets macOS Claude release qualification cold-install an exact PyPI release
again without weakening the maintained strict sandbox. It preserves the
supervised-pilot operating model, Python 3.12+ requirement, and metadata-only
privacy boundary.

Install the pinned package:

export CODE_MOWER_PYTHON="$(command -v python3.12)"
pipx install --python "$CODE_MOWER_PYTHON" code-mower==1.0.11
code-mower --version

Hosted agents and CI boxes can use:

uv tool install --python 3.12 code-mower==1.0.11
code-mower --version

What Is New

• Canonical hosted Devin release campaigns dispatch through the Devin Sessions
  API v3 instead of a GitHub issue comment. The API call is the execution
  trigger: it needs a service-user DEVIN_API_KEY with the UseDevinSessions
  and ViewOrgSessions organization permissions, the opaque org-*
DEVIN_ORG_ID, and the exact OWNER/REPO target acknowledged in
  CODE_MOWER_DEVIN_REPOSITORIES. Matching is against the full slug, so a
  same-name personal fork does not satisfy an organization repository target.
  Credentials are read but never printed or persisted (#770, PR #771).
• A hosted Devin dispatch is bounded and pollable rather than a wait on a bot
  comment. A resume (--resume or watch) polls the stored session id and
  never creates another paid session; --retry-provider devin --apply creates a
  new session only after the prior session is known terminal or its one-hour
  response deadline has expired, so an active or owner-blocked session is polled
  but never duplicated. Accepted retries preserve bounded attempt history
  (#770, PR #771).
• --issue is now optional audit evidence for hosted Devin. When supplied, Code
  Mower records the existing campaign marker on the issue; it does not post
  @devin run and does not depend on a bot reply. Cursor Cloud Agent keeps the
  issue-comment transport and its own five-check profile (#770, PR #771).
• An informational Devin attempt that stays active but cannot be completed can
  be closed out with release campaign dispose, which records a terminal,
  metadata-only disposition without inventing a result or contacting Devin again
  (#770, PR #771).

What Is Fixed

• macOS Claude release campaigns can cold-install an exact PyPI release again
  inside the maintained strict sandbox. Claude Code's macOS sandbox denies the
  Security.framework call pip's default platform trust store makes
  (OSStatus -26276), so a macOS Claude qualification prompt now runs pip with
  its TLS-verifying legacy (certifi) certificate path and no inherited pip
  configuration. Certificate verification stays enabled -- no trusted-host
  option, no disabled TLS, and no unsandboxed command -- and the sandbox, domain
  allowlist, home denials, and disabled escape hatch are unchanged. Linux Claude
  runs and every other provider keep pip's default certificate path. A
  certificate failure that survives this path always classifies as a network
  package-install failure, never sandbox_permission and never package_index;
  a non-certificate index response such as a 404 still classifies as
  package_index (#769, PR #772). See
  macOS Claude sandbox certificate path.

Provider Posture

This release does not change reviewer authority. Codex audit and Claude audit
remain the established reviewer lanes with merge authority; Gitar stays
informational corroboration. Devin remains an opt-in paid lane
(enabled_by_default: false, trigger_policy: manual, spend_policy: paid)
and an informational reviewer unless repository-specific evidence promotes it
under the lane promotion policy. A successful hosted
dispatch is transport evidence, not builder-quality or reviewer-promotion
evidence.

Run A Qualification Campaign

Qualify one provider environment directly when a full campaign is unnecessary:

code-mower release qualify \
  --release-tag v1.0.11 \
  --package-spec code-mower==1.0.11 \
  --output adoption-result.json \
  --execute

Preview a campaign with established local providers required and experimental or
hosted providers informational:

code-mower release campaign create \
  --release-tag v1.0.11 \
  --package-spec code-mower==1.0.11 \
  --providers claude,codex,antigravity,muse,cursor_cloud_agent,devin \
  --required-providers claude,codex \
  --repo-slug OWNER/REPO

Apply only after the preview and adoption doctor are clean:

code-mower doctor --adoption --repo OWNER/REPO
code-mower release campaign dispatch \
  --release-tag v1.0.11 \
  --required-providers claude,codex \
  --apply \
  --repo-slug OWNER/REPO \
  --issue ISSUE_NUMBER
code-mower release campaign watch --release-tag v1.0.11

A hosted Devin attempt needs --repo-slug OWNER/REPO and its API environment;
--issue is optional for that lane. See
Devin Setup.

Preview the closed cloud bundle, then upload it explicitly:

code-mower release campaign upload --release-tag v1.0.11 --json
code-mower release campaign upload --release-tag v1.0.11 --yes --json

Qualification writes the closed code_mower.adoptionResult.v1 artifact.
Campaign upload converts terminal results into additive adoption_run events.
It does not upload source, raw diffs, prompts, transcripts, issue body text, raw
provider output, authentication output, local paths, or secrets.

Recommended Update

For an existing pipx install:

export CODE_MOWER_PYTHON="$(command -v python3.12)"
PIP_NO_CACHE_DIR=1 pipx install --force --python "$CODE_MOWER_PYTHON" code-mower==1.0.11
code-mower --version
code-mower board list

For hosted agents using uv:

uv tool install --python 3.12 --reinstall --refresh-package code-mower code-mower==1.0.11
code-mower --version

--refresh-package takes a package name as its value, so the first
code-mower is the cache-refresh target and code-mower==1.0.11 is the single
package argument.

Restart a Board that still serves an older package. For existing repositories,
review migration setup-drift output in a pull request before applying any
generated changes.

Quality And Privacy Proof

The implementation PRs passed package CI on Python 3.12, 3.13, and 3.14 and
exact-head peer audits with the author lane excluded. The audits found and
corrected duplicate-session, repository-scope, and package-install failure
classification defects before merge.

Cloud sharing remains opt-in and dry-run first. The default release campaign
works locally without a CodeMower.com account.