chore(release): 0.11.0

[client-software-ci]

0.11.0 (2026-08-20)

⚠ 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 (fix: resolve system commands from trusted dirs to prevent PATH injection #351)
• do not cache failed command lookups (fix: resolve system commands from trusted dirs to prevent PATH injection #351)
• address automated review findings on the trusted-path resolver (fix: resolve system commands from trusted dirs to prevent PATH injection #351)

[github-actions]

Duplicate entry: lines 5 and 6 are the same commit (3252e69) listed twice — once with the PR number and once without.

This looks like python-semantic-release 10.x's parse_squash_commits (default on) splitting the squash-merge commit body. That body literally contains a bullet * feat!: shorten the session working directory name for Windows MAX_PATH, so the merge summary and the embedded bullet each get parsed as a feat, both resolving to the same hash.

Worth either setting parse_squash_commits = false under [tool.semantic_release.commit_parser_options] in pyproject.toml, or hand-removing the duplicate line before merging — otherwise every future squash-merged PR whose body repeats its conventional-commit subject will double up in the changelog.

[github-actions]

Missing BREAKING CHANGES section for 0.11.0.

3252e69 is a feat!: commit with an explicit BREAKING CHANGE: footer -- the on-disk session working directory name is no longer prefixed with the session id, and the embedded-files subdir is now ef<random> instead of embedded_files<random> (the footer even names a known downstream consumer). The changelog template renders a breaking-changes block when release["elements"] contains breaking, and prior releases (0.10.0, 0.8.0, 0.7.0, ...) have one, but this entry lists the change only under Features.

So the one thing a consumer most needs to see when bumping to 0.11.0 is absent from the release notes. Suggest adding the breaking-change text manually before merge, summarizing the footer: the working directory name no longer carries the session id and the embedded files subdirectory is renamed, while Session.working_directory, Session.files_directory, and OPENJD_SESSION_WORKING_DIR are unchanged -- anything that pattern-matches the directory name must be updated.

Related: the version was bumped as a minor (0.11.0) rather than a major, which is expected given major_on_zero = false in pyproject.toml -- which makes this changelog text the only signal consumers get about the break.

[github-actions]

The embedded_files<random> -> ef<random> rename described here did not actually land on this head. Session._create_files_directory still passes the long prefix (src/openjd/sessions/_session.py:2193):

return TempDir(
    dir=self.working_directory,
    prefix="embedded_files",
    user=self._user,
    logger=self._logger,
)

grep -rn 3Cprefix="ef"3E src/ test/ finds nothing, and 3252e69 (#348) touched only _session.py, _tempdir.py and test_session.py, leaving _create_files_directory untouched — its commit message says it intended to shorten this prefix, but that hunk is absent.

So the entry documents a breaking rename that consumers cannot observe. Either drop that clause, or land the prefix change before cutting 0.11.0 — the latter seems to be the intent, since the point of #348 was recovering MAX_PATH budget and embedded_files costs 12 more characters than ef on every embedded-file path.

[github-actions]

Two entries the release tooling generated at 1bdff8f were dropped in the hand-edit at 9266f55, and one of them is arguably the most consequential change in the release for downstream consumers:

• fix: raise openjd-model floor to >= 0.11.4 (ea0ea7f) — this narrows the accepted dependency range from openjd-model >= 0.11.2,< 0.12 to >= 0.11.4,< 0.12. Anyone pinned to 0.11.2/0.11.3 will fail to resolve 0.11.0 of this package, and the changelog now gives them no explanation. A raised dependency floor belongs in the notes.
• fix: use absolute paths for system commands to prevent PATH injection (d3b978f) — a security fix. Folding it into the chore(github): bump actions/checkout from 4 to 7 #349 line is defensible if that was intentional, but it is worth being explicit given it is the first commit in that hardening series.

[github-actions]

These PR references are wrong — two of the three point at unrelated, still-open Dependabot PRs:

ref	actual PR	state
#349	chore(github): bump actions/checkout from 4 to 7	open, unmerged
#350	chore(deps): update hatch requirement from ==1.17.* to ==1.18.*	open, unmerged
#351	fix: resolve system commands from trusted dirs to prevent PATH injection	merged 2026-08-18 as d0af2c3

All four commits in the trusted-path series (d3b978f, 419b434, 3744653, 3574ced) arrived through #351 alone. So the three lines here should collapse to a single entry citing #351, rather than three entries citing two dependency-bump PRs.

Published notes with wrong PR links are hard to walk back — they send readers auditing a security fix to a GitHub Actions version bump. Worth fixing before the tag.

[github-actions]

Minor, but two cosmetic regressions from the tooling-generated version at 1bdff8f:

1. Date moved backwards. The generated header said 2026-08-19; this says 2026-08-18. 08-18 is when fix: resolve system commands from trusted dirs to prevent PATH injection #351 merged, not when 0.11.0 is being cut — the release commit itself is dated 2026-08-19. Every other heading in this file records the release date.
2. Commit links dropped. Every prior entry in this file carries a ([hash](commit-url)) suffix. The new entries have none, so this release is the only one a reader cannot trace back to code without going through the PR.
3. Several of the new lines have trailing whitespace (lines 3, 5, 7, 9) — harmless but likely unintended.

[github-actions]

This line files a behavior-changing hardening as a plain bug fix, and the behavior change is the part consumers need to know about.

Before 419b434, sudo/setsid/pgrep were bare names in the argv and resolved by execvp through PATH — so any install location worked. After it, _system_commands.system_command_path scans a closed list and raises SystemCommandNotFoundError when the command is not in it (src/openjd/sessions/_system_commands.py:48):

TRUSTED_SYSTEM_DIRECTORIES = (
    "/run/wrappers/bin", "/run/current-system/sw/bin",
    "/usr/bin", "/bin", "/usr/sbin", "/sbin",
)

/usr/local/bin and /opt/*/bin are absent, and deliberately so — they are commonly group-writable, so trusting them would weaken the fix. That is the right call, but it means a host whose sudo or setsid lives there stops being able to start cross-user sessions at all. _start_subprocess resolves both on the launch path (src/openjd/sessions/_subprocess.py:598, :615), so the failure lands at session start, not on a rarely-taken branch.

Two things worth adding to the notes:

1. Say that PATH is no longer consulted, and name the trusted list, so an operator hitting SystemCommandNotFoundError after upgrading can recognize it as intended rather than a regression. The BREAKING CHANGES section already exists in this release; an operational note there costs nothing.
2. Say that this is the fix for a reported PATH-injection vulnerability. 419b434 cites HackerOne 3942741, CWE-426; the current wording reads as a portability tidy-up, so downstream consumers who triage changelogs for security-relevant releases will not flag 0.11.0 from this line.

[github-actions]

The hand-edit dropped the commit-hash links that every other entry in this file carries, and this section is not just read on GitHub — it is extracted and published verbatim.

.github/workflows/release_publish.yml feeds .github/scripts/get_latest_changelog.py, which slices everything from the top of the file down to the second ^##\s heading and prints it as the release body. So this section becomes the GitHub Release notes for 0.11.0 as-is.

Two consequences of removing the ([3252e69](.../commit/3252e69...)) suffixes:

• Bare #348 renders as a link inside a GitHub Release body, but the commit is no longer reachable from the notes at all. Every prior release in this file (0.10.14 back to 0.7.x) links the commit; 0.11.0 would be the first that does not.
• The .semantic_release/CHANGELOG.md.j2 template emits those links unconditionally, so the next semantic-release run will produce the linked form again for 0.11.1+. That leaves 0.11.0 as a one-off gap in the middle of an otherwise uniform file rather than a deliberate new convention.

If the goal was to drop the redundant duplicate feat! line and merge the four trusted-path commits into one readable entry — both reasonable — the commit links can be kept while doing it: * … (#348) ([3252e69](https://github.com/OpenJobDescription/openjd-sessions-for-python/commit/3252e693eec2cb31a0546f12e0e39f5778d9eb9d)).

Minor, same edit: the five new headings/bullets carry trailing spaces (### ⚠ BREAKING CHANGES , * … (#348) , ### Bug Fixes , * … (#349) ). Two trailing spaces are a Markdown hard line break, and one is just noise; no other line in the file has them.

[github-actions]

These two entries document fixes to code that has never been released, so they are noise for anyone reading 0.11.0's notes.

src/openjd/sessions/_system_commands.py is created in this same release — 419b434 adds it (+147 lines, the entry on line 9). The two lines below it then fix that brand-new file:

• 3574ced "do not cache failed command lookups" — the negative-result caching it removes was introduced by 419b434. git show 419b434 --stat shows _system_commands.py | 147 +++++ (new file); git show 3574ced --stat shows it modifying that same file.
• 3744653 "address automated review findings on the trusted-path resolver" — same window, same file, and the summary describes review churn rather than an observable behavior change.

A consumer upgrading 0.10.14 -> 0.11.0 never saw the buggy cache, so "do not cache failed command lookups" describes a state they were never in, and "address automated review findings" gives them nothing to act on. Every other entry in this file describes a delta from the previously released version.

Suggest collapsing lines 9-11 into the single entry that is actually consumer-visible, e.g.:

* resolve system commands from trusted absolute directories instead of PATH (#351)

This matters more than usual because the notes are published verbatim: .github/workflows/release_publish.yml -> .github/scripts/get_latest_changelog.py slices from the top of the file to the second ^##\s heading and prints it as the GitHub Release body. Three bullets where one applies makes the one real change harder to spot.