What happened?
When exporting a session to JSONL, the app_version and session.info.version fields are always written as the literal string "local", regardless of which release build is actually running. This applies to release builds (e.g. v2026.5.12 from GitHub Releases), not just dev builds.
This makes debugging user-reported regressions harder: we cannot tell from a session export which release the user was on, and have to ask the user to confirm out-of-band.
Which area seems affected?
Model harness, prompts, tools, or session mechanics
How much does this affect you?
Minor issue or polish
Steps to reproduce
- Install any release build of PawWork (verified on v2026.5.11 through v2026.5.12).
- Have a session.
- Export the session JSONL.
- Grep the export: `grep '"app_version"' .json` and `grep '"version"' .json`.
- Both fields read `"local"`.
What did you expect to happen?
`app_version` and `session.info.version` should contain the actual installed release version (e.g. `v2026.5.12`) so that user-submitted session exports are self-identifying for triage.
PawWork version
v2026.5.12 (and earlier; confirmed across 5 exports from 2026-05-07 to 2026-05-12)
OS version
macOS 15 / Darwin 25.3.0 — 25.4.0
Can you reproduce it again?
Yes, every time
Diagnostics
Confirmed across 5 separate session exports in `docs/debug-session-log/` collected between 2026-05-07 and 2026-05-12; all show `"app_version": "local"` and `"version": "local"` regardless of release.
Likely cause: the version constant injected at export time is not wired to the build's actual release version string, and falls back to a dev-time `"local"` literal.
Discovered while investigating PawWork#554-related session-export RCA on 2026-05-12.
What happened?
When exporting a session to JSONL, the
app_versionandsession.info.versionfields are always written as the literal string"local", regardless of which release build is actually running. This applies to release builds (e.g. v2026.5.12 from GitHub Releases), not just dev builds.This makes debugging user-reported regressions harder: we cannot tell from a session export which release the user was on, and have to ask the user to confirm out-of-band.
Which area seems affected?
Model harness, prompts, tools, or session mechanics
How much does this affect you?
Minor issue or polish
Steps to reproduce
What did you expect to happen?
`app_version` and `session.info.version` should contain the actual installed release version (e.g. `v2026.5.12`) so that user-submitted session exports are self-identifying for triage.
PawWork version
v2026.5.12 (and earlier; confirmed across 5 exports from 2026-05-07 to 2026-05-12)
OS version
macOS 15 / Darwin 25.3.0 — 25.4.0
Can you reproduce it again?
Yes, every time
Diagnostics
Confirmed across 5 separate session exports in `docs/debug-session-log/` collected between 2026-05-07 and 2026-05-12; all show `"app_version": "local"` and `"version": "local"` regardless of release.
Likely cause: the version constant injected at export time is not wired to the build's actual release version string, and falls back to a dev-time `"local"` literal.
Discovered while investigating PawWork#554-related session-export RCA on 2026-05-12.