Git tag created as literal `v{version}` instead of interpolated version number in NX Release

[programm-ingovals]

Current Behavior

When running nx release patch --skip-publish, the git tag is created as the literal string v{version} instead of interpolating the actual version number.

Example:

• Expected tag: v1.0.6
• Actual tag created: v{version}

This happens consistently on every release, requiring manual deletion of the incorrect tag and creation of the correct one.

Expected Behavior

The git tag should be created with the interpolated version number, for example:

• v1.0.1
• v1.0.2
• v1.0.6

The tag name should use the actual version from the release, not the literal template string.

GitHub Repo

No response

Steps to Reproduce

1. Set up an Nx workspace with fixed versioning and release configuration (see configuration below)
2. Make some commits that should trigger a version bump
3. Run: pnpm exec nx release patch --skip-publish
4. Check created tags: git tag -l
5. Observe that a tag named v{version} is created instead of the actual version

Workaround currently used:

git tag -d "v{version}"
git tag v1.0.6  # manually create correct tag
git push origin v1.0.6

Nx Report

Node           : 22.15.0
OS             : linux-x64
Native Target  : x86_64-linux
pnpm           : 10.24.0

nx             : 22.3.3
@nx/js         : 22.3.3
@nx/workspace  : 22.3.3
@nx/devkit     : 22.3.3
@nx/dotnet     : 22.3.3
@nx/docker     : 22.3.3
typescript     : 5.9.3
---------------------------------------
Registered Plugins:
@nx/dotnet
@nx/js/typescript
@nx/docker

Failure Logs

Output from `nx release patch --skip-publish`:


 NX   Running release version for project: @almenni/contributions

@almenni/contributions 🏷️  Resolved the current version as 1.0.5 from git tag "v1.0.5", based on releaseTagPattern "v{version}"
@almenni/contributions ❓ Applied semver relative bump "patch", from the given specifier, to get new version 1.0.6
@almenni/contributions ✍️  New version 1.0.6 written to manifest: packages/contributions/package.json

[... similar output for other projects ...]

 NX   Updating pnpm lock file
 NX   Staging changed files with git
 NX   Generating an entry in packages/contributions/CHANGELOG.md for v1.0.6
 NX   Staging changed files with git
 NX   Committing changes with git
 NX   Tagging commit with git
 NX   Skipped publishing packages.


The command completes successfully, but checking tags afterward shows:

$ git tag -l "v{version}" "v1.0.6"
v{version}


The literal `v{version}` tag is created instead of `v1.0.6`.

Package Manager Version

No response

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

Relevant Configuration

nx.json (release section):

{
  "release": {
    "projects": ["packages/*", "apps/*"],
    "projectsRelationship": "fixed",
    "version": {
      "conventionalCommits": true
    },
    "changelog": {
      "projectChangelogs": true,
      "workspaceChangelog": false
    },
    "git": {
      "commit": true,
      "commitMessage": "chore: release v{version}",
      "tag": true
    }
  }
}

Note: We have not explicitly configured releaseTagPattern - we expect it to use the default pattern.

Environment

• Operating System: Linux (WSL2 Ubuntu on Windows)
  • OS Version: Linux 6.6.87.2-microsoft-standard-WSL2
• Package Manager: pnpm 10.24.0
• Workspace Type: Monorepo with multiple apps and packages
• Version Control: Git

Additional Context

• This has been occurring consistently across multiple releases
• The commit message interpolation works correctly: "chore: release v1.0.6" is created properly
• Only the git tag creation fails to interpolate the version variable
• We use fixed versioning with all projects releasing together
• Conventional commits are enabled for automatic version bump detection

Attempted Solutions

We have tried:

1. Not specifying any tag configuration (relying on defaults)
2. Explicitly setting releaseTagPattern: "v{version}" in nx.json
3. Using the legacy git.tagMessage field (which is for tag annotations, not tag names)

None of these approaches resolved the issue. The tag is always created as the literal string v{version}.