fix(list-projects): omit type=all query param — self-hosted Infisical rejects it

[petersimmons1972]

Problem

list-projects always sends ?type=${data.type} to GET /v1/workspace. When type is all (the schema default), self-hosted Infisical rejects type=all as an invalid enum value and returns HTTP 422, so the tool fails on every default call against self-hosted instances.

Fix

Only append ?type=<value> for the real enum values; omit the query parameter entirely when type is unset or "all". No behavior change for Infisical Cloud (which tolerates type=all).

}>(`${hostUrl}/v1/workspace${data.type && data.type !== "all" ? `?type=${data.type}` : ""}`, {

One line in src/index.ts. npm run build passes.

Context

This supersedes #19 (which inadvertently committed a prebuilt dist/ bundle, +780 lines — dist/ is gitignored upstream and built via the build script, so it doesn't belong in the diff). This PR is the same source fix, isolated to the one line. Same root cause as #10 and #15.

Verified against a self-hosted Infisical instance: list-projects returns 422 before, succeeds after.

Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com

[greptile-apps]

Greptile Summary

This PR fixes a one-line bug where list-projects always appended ?type=all to the workspace API request, causing HTTP 422 errors on self-hosted Infisical instances that reject "all" as an invalid enum value.

• The query parameter is now omitted when type is "all" (the default) or unset, matching the expected API contract for both self-hosted and cloud instances.
• The data.type value is Zod enum-validated before interpolation, so no injection risk is introduced through the query string.

Confidence Score: 4/5

Safe to merge — the change is isolated to a single conditional expression that removes a query parameter known to break self-hosted deployments.

The fix is minimal and correct: Zod enum validation means data.type is always a non-empty string, so the only nit is the redundant data.type && truthy guard. The core logic — omitting the query param when type is "all" — accurately addresses the reported 422 behaviour.

No files require special attention.

Important Files Changed

Filename	Overview
src/index.ts	Single-line fix that conditionally omits ?type=all from the GET /v1/workspace request; the redundant data.type && guard is the only minor nit.

_{Reviews (1): Last reviewed commit: "fix(list-projects): omit type=all query ..." | Re-trigger Greptile}

[greptile-apps]

The data.type && truthy check is redundant. Because the Zod schema declares .default("all"), data.type is always a non-empty string after parsing — it can never be undefined, null, or "". The guard adds no protection and slightly obscures the intent of the condition.

Suggested change

	}>(`${hostUrl}/v1/workspace${data.type && data.type !== "all" ? `?type=${data.type}` : ""}`, {
	}>(`${hostUrl}/v1/workspace${data.type !== "all" ? `?type=${data.type}` : ""}`, {

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[infisical-cla-app]

📝 Contributor License Agreement required

Before this PR can merge, every contributor must sign the Infisical CLA.
Signing is quick: sign in with GitHub, review the CLA, and accept.

👉 Sign the CLA

Commits from unrecognized email addresses (not linked to a GitHub account):

• petersimmons1972@gmail.com

Please link this email to your GitHub account and push again, or sign with the account that owns it.

Once everyone has signed, the check updates automatically — no need to close and reopen the PR.