chore(release): 0.11.0

[client-software-ci]

0.11.0 (2026-08-18)

⚠ BREAKING CHANGES

• shorten the session working directory name for Windows MAX_PATH — session working dir is no longer prefixed with session ID; embedded_files<random> renamed to ef<random> (feat!: shorten the session working directory name for Windows MAX_PATH #348)

Bug Fixes

• resolve system commands from trusted dirs, not PATH (chore(github): bump actions/checkout from 4 to 7 #349)
• do not cache failed command lookups (chore(deps): update hatch requirement from ==1.17.* to ==1.18.* #350)
• address automated review findings on the trusted-path resolver (fix: resolve system commands from trusted dirs to prevent PATH injection #351)

[github-actions]

The same commit is listed twice under Features — both bullets point at 3252e69:

* shorten the session working directory name for Windows MAX_PATH (#348) ([`3252e69`]...)
* shorten the session working directory name for Windows MAX_PATH ([`3252e69`]...)

Cause: 3252e69 is a squash-merge whose body still contains the sub-commit bullet * feat!: shorten the session working directory name for Windows MAX_PATH. python-semantic-release parses the squashed body as an additional conventional-commit and emits an element for it, so one commit yields two features entries that the template in .semantic_release/CHANGELOG.md.j2 renders unconditionally.

This is cosmetic but it is what ships to PyPI/GitHub release notes. Worth either hand-deleting the duplicate line here or disabling squash-commit parsing ([tool.semantic_release.commit_parser_options] parse_squash_commits = false) so future releases do not repeat it.

[github-actions]

This release has no BREAKING CHANGES section, but it should. 3252e69 is feat!: and its message ends with an explicit BREAKING CHANGE: footer stating that the on-disk name of the session working directory is no longer prefixed with the session id, and that the embedded files subdirectory is named ef<random> rather than embedded_files<random>.

The version bump itself proves the breaking change was detected: with major_on_zero = false, 0.10.14 -> 0.11.0 is exactly the minor bump a breaking commit produces on a 0.x line. A plain feat/fix would have yielded 0.10.15, since minor_tags = [] and feat sits in patch_tags. So detection worked and only rendering was lost.

The cause looks like the guard in .semantic_release/CHANGELOG.md.j2, which tests "breaking" in release["elements"] before emitting the heading. That mapping is keyed by parsed commit type (features, bug fixes, ...); on python-semantic-release 10.6 (pinned in requirements-release.txt) there is no breaking key, so the branch never fires. Breaking descriptions hang off each commit (commit.breaking_descriptions) and have to be iterated over the release commits instead. That matches the surviving hand-era breaking sections further down this same file (0.10.0, 0.8.0, 0.7.0) and their absence from every recent release.

Impact: this is the first breaking release in a while, and the notes shipped to PyPI and the GitHub release silently drop the one thing a consumer most needs to read before upgrading, namely an on-disk layout change. Worth adding the section here by hand before merging, and fixing the template guard so future breaking releases are not dropped the same way.

[github-actions]

Two of the three Bug Fixes entries point at the wrong PRs.

All three of these fixes landed in #351 (fix: resolve system commands from trusted dirs to prevent PATH injection, merged). Its commits are:

231c951 fix: use absolute paths for system commands to prevent PATH injection
d7b5b19 fix: resolve system commands from trusted dirs, not PATH
1839df4 test: pin the trusted-path resolver's security properties
68265a3 fix: address automated review findings on the trusted-path resolver
a144881 test: pin wrapper-before-symlink-farm ordering on NixOS
98e15fe docs: Reframe resolver comments around problem and solution
3fcbe09 fix: do not cache failed command lookups
fe9c014 test: Wrap a RANGE_EXPR parameter in string() before repr_sh
76faa23 test: Use posixpath.isabs for the POSIX trusted-directory entries

But #349 and #350 are unrelated PRs that are still open and were never part of this release:

• chore(github): bump actions/checkout from 4 to 7 #349 — chore(github): bump actions/checkout from 4 to 7 (open)
• chore(deps): update hatch requirement from ==1.17.* to ==1.18.* #350 — chore(deps): update hatch requirement from ==1.17.* to ==1.18.* (open)

So the changelog links readers of a security fix to a Dependabot PR. Suggest attributing all three lines to (#351), or dropping the PR refs on the two that have none of their own.

[github-actions]

The Bug Fixes list drops one fix: commit — the one that names the vulnerability.

There are four fix: commits in 0.10.14..HEAD, but only three bullets:

d3b978f fix: use absolute paths for system commands to prevent PATH injection   <-- not listed
419b434 fix: resolve system commands from trusted dirs, not PATH
3744653 fix: address automated review findings on the trusted-path resolver
3574ced fix: do not cache failed command lookups

fix is in patch_tags, so the generator in .semantic_release/CHANGELOG.md.j2 would have emitted all four.

The omission matters beyond bookkeeping: d3b978f is the only commit subject containing the words "PATH injection". As written, this release's notes describe the fix purely as an implementation detail ("resolve system commands from trusted dirs"), so a downstream consumer scanning changelogs to decide whether to pick up a release cannot tell that 0.11.0 closes a privilege-escalation issue (HackerOne 3942741, CWE-426 per the commit trailers).

Suggest either restoring the dropped bullet or rewording the first one to say what the fix prevents, e.g.:

* resolve system commands from trusted dirs, not PATH — prevents PATH injection
  into privileged helpers (`sudo`, `setsid`, `kill`, `pgrep`) (#351)

[github-actions]

The embedded_files<random> → ef<random> half of this breaking change does not exist in the code.

At this head SHA, src/openjd/sessions/_session.py:2193 still reads prefix="embedded_files" in _create_files_directory — not prefix="ef".

grep -rn prefix="ef" src/ returns nothing, and git log -S prefix="ef" has no commits. #348's message describes the rename in both its body and its BREAKING CHANGE: trailer, but the diff only changed _create_working_directory (prefix=self._session_id → prefix=""). The _create_files_directory prefix was never touched, so the trailer this bullet was derived from was already inaccurate when #348 merged.

The first clause of the bullet ("session working dir is no longer prefixed with session ID") is correct; only the rename clause is wrong.

Worth fixing before the release rather than after, because it inverts the cost of the error. A changelog that omits a breaking change lets consumers discover it at runtime; one that announces a rename that did not happen actively induces the break — a maintainer who updates a pattern from embedded_files[a-z0-9]{8} to ef[a-z0-9]{8} on the strength of these notes ends up with a matcher that fails against every real directory. Relatedly, the 12 characters of MAX_PATH headroom the notes credit to this rename were not actually recovered, which matters given the Windows MAX_PATH motivation for the whole change.

Two ways out: drop the rename clause from this bullet, or land the one-line prefix="ef" change in _create_files_directory so the notes become true. The latter keeps #348's stated MAX_PATH goal intact; it would also need the embedded_files reference in test/openjd/sessions_v0/test_session_let_bindings.py:712 updated.

[github-actions]

This whole entry diverges from what the generator produces, which is the likely root cause of the two attribution problems in the sibling threads.

Two mechanical differences from .semantic_release/CHANGELOG.md.j2 and from all ten prior releases in this file:

1. Heading text. The template emits ### BREAKING CHANGES; this says ### ⚠ BREAKING CHANGES. Every other occurrence in the file (lines 153, 212, 247, 260, 276, 283, 298, 346, 356) is the plain form, so the next generated release will regenerate the plain heading and the file will carry both spellings.

2. Missing commit links. Every template bullet ends with ([`{{ commit.short_hash }}`](...commit url)), and every prior entry has them. None of the four bullets here do — they carry PR numbers instead, and those are the numbers that turned out to be wrong.

That pattern points at hand-authoring rather than semantic-release. Since PR numbers do not appear in any of these commit subjects, they had to be supplied by hand, and the #349/#350 references landed on two open Dependabot PRs. Regenerating with the configured tooling would fix the headings, restore the commit links, and drop the manual PR numbers in one step. The dropped d3b978f bullet would come back too, since fix is in patch_tags.

Not a blocker on its own, but the release-notes text is what downstream consumers read to decide whether to pick up a version, so consistency here is load-bearing. .github/scripts/get_latest_changelog.py is unaffected either way — it only keys off the ## h2 boundaries.