Skip to content

Releases: opencue/gitguardex

v7.0.26

23 Apr 16:23
41c7d29

Choose a tag to compare

GitGuardex v7.0.26

Changes since v7.0.25.

v7.0.26

  • Bumped @imdeadpool/guardex from 7.0.25 to 7.0.26 so npm can publish a fresh version after v7.0.25 reached GitHub Releases while the registry stayed on 7.0.24.
  • README now documents both npx skills add recodeee/ and npx skills add recodeee/gitguardex, and explains why the picker shows gitguardex instead of a separate guardex skill.
  • Keep the release scoped to version metadata plus the already-merged README installer guidance on main; no additional CLI/runtime behavior changed in this lane.

v7.0.25

23 Apr 10:43
776da31

Choose a tag to compare

GitGuardex v7.0.25

Changes since v7.0.24.

v7.0.25

  • Bumped @imdeadpool/guardex from 7.0.24 to 7.0.25 so npm and GitHub Releases can ship the current main payload.
  • The bundled GitGuardex Active Agents VS Code companion now self-heals stale repo-scan ignore settings in older repos, keeps plain managed sandboxes visible in Source Control, and preserves cleanup truth so the tree matches actual sandbox state.
  • Bumped the shipped Active Agents companion manifests from 0.0.8 to 0.0.9 so local VS Code installs can pick up the newer workspace build and show the refreshed extension version from this release.

v7.0.24

22 Apr 21:55
48afde8

Choose a tag to compare

GitGuardex v7.0.24

Changes since v7.0.23.

v7.0.24

  • Bumped @imdeadpool/guardex from 7.0.23 to 7.0.24 so GitHub Releases and the npm publish retry can advance together after v7.0.23 landed on GitHub but not on npm.
  • Release verification no longer loses its base ref on tag-triggered runs, so the publish workflow keeps the history it needs before packing and publish checks.
  • Keep the release scoped to version and release automation metadata only; the packaged Guardex CLI payload stays aligned with the already-verified main branch contents.

v7.0.23

22 Apr 21:27
cbf7e06

Choose a tag to compare

GitGuardex v7.0.23

Changes since v7.0.21.

v7.0.23

  • Bumped @imdeadpool/guardex from 7.0.22 to 7.0.23 so GitHub release and npm can advance together after 7.0.22 reached npm without a matching published GitHub release.
  • Active Agents stays easier to scan and more truthful: the package repo remains the canonical source, inspect/install paths stay loadable across VS Code churn, and session rows group under worktrees with clearer merged-cleanup truth.
  • Guardex prompt and finish guidance now pushes faster phase-based execution, keeps helper behavior single-sourced, and avoids fragmented probe loops when cleanup or branch-deletion races appear.

v7.0.22

  • Bumped @imdeadpool/guardex from 7.0.21 to 7.0.22 so npm can publish the next release from the current merged mainline.
  • The shipped main payload already includes lower-token prompt slices, SCM-selected lane visibility, truthful merged-cleanup evidence, the Active Agents brand/icon refresh, and the remaining CLI extraction cleanups without changing Guardex behavior.
  • Keep the release scoped to version and release metadata only; the package payload stays the same as the verified main branch contents.

v7.0.21

22 Apr 13:15
78a06fa

Choose a tag to compare

GitGuardex v7.0.21

Changes since v7.0.20.

v7.0.21

  • Bumped @imdeadpool/guardex from 7.0.20 to 7.0.21 so npm can publish the next release from the current merged mainline.
  • Keep the release scoped to version and release metadata only; the package payload stays the same as the verified main branch contents.
  • Published-release automation will pick up this new package version once the matching GitHub release is created.

v7.0.20

22 Apr 10:16
cb2b33a

Choose a tag to compare

GitGuardex v7.0.20

Changes since v7.0.16.

v7.0.20

  • The VS Code Active Agents tree now exposes worktree-owned SCM changes and lock ownership directly, so operators can see which sandbox owns a dirty file before they act.
  • Guardex now keeps merged cleanup evidence truthful by recording final cleanup proof only after the merge and cleanup state is actually available.
  • Install-surface verification cleanup on main is easier to maintain without changing the shipped CLI surface.
  • Bumped the release from 7.0.197.0.20 so the shipped Active Agents visibility and cleanup-evidence refinements land on a fresh publishable npm version.

v7.0.19

  • gx setup and gx doctor now accept targeted managed-file recovery after --force, so gx doctor --force scripts/review-bot-watch.sh repairs the named managed file instead of failing on an unknown argument.
  • Managed-file conflict output now teaches both recovery forms directly: --force <managed-path> for one file and plain --force for whole-surface rewrites.
  • GitGuardex now keeps small-task routing caveman-only by default and makes working VS Code agent lanes easier to spot at a glance while keeping the CLI-owned install-surface rollout intact.
  • Bumped the release from 7.0.187.0.19 so the shipped setup/doctor recovery and UX refinements land on a fresh publishable npm version.

v7.0.18

  • GitGuardex now keeps the install workflow in gx itself: gx branch ..., gx locks ..., gx worktree prune, gx migrate, and user-level agent-skill install now own the agent lifecycle instead of teaching pasted repo scripts as the primary surface.
  • Fresh installs switch repo hooks to tiny gx hook run ... shims, stop copying repo-local workflow implementations and repo-local skills, and stop injecting Guardex-managed agent:* package scripts into consumer repos.
  • gx migrate can move older repos onto the smaller CLI-owned install surface while preserving the managed AGENTS block, lock registry state, hook shims, required gitignore entries, and the repo-local helper assets that still carry local state.
  • Bumped the release from 7.0.177.0.18 so the shipped CLI-owned install-surface changes land on a fresh publishable npm version.

v7.0.17

  • Restored the published npm package name to @imdeadpool/guardex after the @imdeadpool/gitguardex rename only changed the package identity locally and could not rename the existing npm registry entry.
  • README/install/tutorial/self-update surfaces now point back at @imdeadpool/guardex while keeping GitGuardex as the product/repo brand and gitguardex as the long-form command.
  • Bumped the release from 7.0.167.0.17 because @imdeadpool/guardex@7.0.16 is already published on npm.

v7.0.16

21 Apr 15:04
495c867

Choose a tag to compare

GitGuardex v7.0.16

Changes since v7.0.15.

v7.0.16

  • gx doctor now keeps nested repo repair runs visibly progressing, and overlapping integration work stays off the protected base branch instead of trying to merge back on main.
  • Cleanup and finish flows are less brittle: codex-agent no longer waits on PRs that can never exist, and prune cleanup now walks both managed worktree roots so stale sandboxes get removed consistently.
  • Mirror-sync diagnostics are quieter: when the mirror PAT is unset, Guardex now skips the sync path instead of marking the run red, and shared ralplan lanes stay easier to identify during handoff/debugging.
  • Bumped @imdeadpool/guardex from 7.0.157.0.16 after npm rejected a republish over the already-published 7.0.15.

v7.0.15

21 Apr 11:03
0ec3615

Choose a tag to compare

GitGuardex v7.0.15

Changes since v7.0.12.

v7.0.15

  • gx doctor no longer blocks recursive nested protected-repo repairs on child PR merge waits; nested sandboxes now force --no-wait-for-merge so the parent repair loop can continue.
  • gx setup can now refresh managed files from protected main through a temporary sandbox branch/worktree, sync the managed outputs back to the visible base checkout, and prune the sandbox afterward.
  • Bumped @imdeadpool/guardex from 7.0.147.0.15 after npm rejected a republish over the already-published 7.0.14.

v7.0.14

  • Bumped @imdeadpool/guardex from 7.0.137.0.14 after npm rejected a republish over the already-published 7.0.13.
  • No package payload changes beyond the release metadata bump; this release exists so npm publish can proceed with a fresh semver.

v7.0.13

  • gx status and gx setup now present the Claude companion as oh-my-claudecode while still installing the published npm package oh-my-claude-sisyphus.
  • When that dependency is inactive or the user declines the optional install, Guardex now prints the upstream repo URL so the missing dependency is explicit instead of hidden behind the npm package name.
  • Bumped @imdeadpool/guardex from 7.0.127.0.13 after npm rejected a republish over the already-published 7.0.12.

v7.0.12

21 Apr 01:42
b21e4b8

Choose a tag to compare

GitGuardex v7.0.12

  • restart into the installed CLI after a successful self-update so the same gx invocation no longer prints a stale pre-update version
  • keep the existing pinned retry guard when npm reports success but leaves old bytes on disk
  • bump @imdeadpool/guardex from 7.0.11 to 7.0.12

v7.0.11

21 Apr 01:18
3faedee

Choose a tag to compare

GitGuardex v7.0.11

  • fix the npm publish workflow trigger so releases run from the published release event or manual dispatch only
  • remove the duplicate tag-push publish path that was leaving extra cancelled deployment cards in the npm environment
  • bump @imdeadpool/guardex from 7.0.10 to 7.0.11 so the replacement release can publish cleanly after 7.0.10 already landed on npm