fix(vault-jwt): correct display name and make it configurable

[matifali]

Closes #1017

Problem

The vault-jwt module's coder_script resource had a hardcoded display_name = "Vault (GitHub)", copy-pasted from the vault-github module. Workspaces using vault-jwt showed the wrong label in the workspace logs.

Fix

• Corrected the hardcoded label to "Vault (JWT)".
• Made it configurable via a new display_name variable (defaults to "Vault (JWT)"), per the "nice to have" in the issue, so users running multiple Vault modules in one workspace can distinguish them.
• Documented the new variable with an example in the README and bumped the module version to 1.3.0 (minor, new input) per CONTRIBUTING.md.

Validation

Existing main.test.ts covers required variables; no behavioral test needed for a display label change. CI will run terraform test and bun test on this PR.

🤖 This PR was created with the help of Coder Agents, and needs a human review. 🧑💻

[github-actions]

Module Scorecard Check

coder/vault-jwt: 67 → 70

✅ Score improvement: 67 → 70 (+3).

Theme	Before	After
Presentation & Onboarding	17 / 25	20 / 25
Integration	—	—
Credential Hygiene	18 / 20	18 / 20
Restricted-Environment	7 / 20	7.5 / 20
Engineering Quality	8 / 10	7 / 10
Overall	67 / 100	70 / 100

Full scorecard for this PR

Presentation & Onboarding	Credential Hygiene	Restricted-Environment Readiness	Engineering Quality	Overall
20 / 25	18 / 20	7.5 / 20	7 / 10	70 / 100

Drilldown

Presentation & Onboarding — 20 / 25

Criterion	Max	Score	Notes
Configuration-mode examples	12	12	Multiple documented examples cover major modes: default OIDC token usage, custom JWT token, non-standard auth path, version pinning, namespace configuration, and group-based role mapping. Each has sensible defaults.
Coder-context framing	8	8	README clearly explains this module authenticates with Vault using JWT from Coder's OIDC provider, names both Coder and Vault, and shows the integration flow (OIDC token → Vault auth → workspace access).
Visual preview	5	0	No image, GIF, or video present. The icon reference is metadata, not an embedded visual preview.

Credential Hygiene — 18 / 20

Criterion	Max	Score	Notes
Secrets marked sensitive	16	14	The vault_jwt_token variable is marked sensitive = true in main.tf. However, the first README example shows vault_jwt_token = "eyJhbGciOiJIUzI1N..." with an inline placeholder JWT, which counts as an inline secret example, capping this at partial credit despite proper variable marking.
Non-hardcoded auth path	4	4	README demonstrates using Coder's OIDC authentication token as the default JWT source, avoiding raw key pasting. The custom JWT example shows generating tokens programmatically via the jwt provider.

Restricted-Environment Readiness — 7.5 / 20

Criterion	Max	Score	Notes
Mirrorable artifact source	10	0	The run.sh script hardcodes https://releases.hashicorp.com/vault/ for downloads with no module variable to override this URL. The vault_cli_version variable only controls which version is fetched from the hardcoded domain, not where to fetch from.
Bring-your-own binary	5	5	The install function in run.sh checks if vault is already installed with the correct version and skips installation: if command -v vault > /dev/null 2>&1; then CURRENT_VERSION=$(vault version... with installation_needed=0. This is documented behavior allowing pre-baked binaries.
Egress transparency	3	1.5	External endpoints are mentioned across examples (https://vault.example.com, https://releases.hashicorp.com/vault/) but there is no dedicated README section enumerating all endpoints contacted at install and runtime with air-gapped notes. Scattered mentions earn at most half.
Runs without sudo	2	1	The run.sh script attempts sudo mv vault /usr/local/bin/vault but falls back to ~/.local/bin/vault if sudo fails, with a note to add to PATH. This is a working fallback for the optional system-wide install, but the fallback requires manual PATH configuration, making it awkward. Earns half.

Engineering Quality — 7 / 10

Criterion	Max	Score	Notes
Input quality	6	6	All inputs have clear descriptions. Sensible defaults provided (vault_jwt_auth_path = "jwt", vault_cli_version = "latest", display_name = "Vault (JWT)"). The vault_cli_version has validation: `can(regex("^(latest
Test coverage	4	1	The main.test.ts only tests required variables with testRequiredVariables, no business logic coverage. No .tftest.hcl file present. Minimal testing story.

Overall — 70 / 100

Raw 52.5 / 75 → round(52.5 / 75 × 100) = 70

Track: Utility (authentication/integration module, not an agent or IDE)

Corrected calculation: 20 + 18 + 7.5 + 7 = 52.5 / 75 → round(52.5 / 75 × 100) = 70 / 100

---

Scored against SCORECARD.md with claude-sonnet-4-5. Language-model scores are advisory.

[Copilot]

Pull request overview

Fixes the vault-jwt module’s workspace log label by removing the incorrect hardcoded coder_script.display_name (“Vault (GitHub)”) and making the label configurable, so multiple Vault modules can be distinguished in a single workspace.

Changes:

• Added a new display_name input variable (defaulting to Vault (JWT)) and wired it into the coder_script resource.
• Updated README examples to reference module version 1.3.0 and documented how to override the log display name.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
registry/coder/modules/vault-jwt/main.tf	Introduces display_name variable and uses it for coder_script.display_name to fix the incorrect label.
registry/coder/modules/vault-jwt/README.md	Updates usage examples to 1.3.0 and documents overriding display_name.

[35C4n0r]

@matifali, we are adding a optional non-critical variable, should we keep it as a patch instead ?

[matifali]

@matifali, we are adding a optional non-critical variable, should we keep it as a patch instead ?

No, per our versioning guidelines. I would prefer to stay consistent and strictly follow versioning.