feat(cli): add --as-superadmin flag to workspace list-remote

[rubenfiszel]

Summary

• wmill workspace list-remote only shows workspaces the caller is a member of (listUserWorkspaces). The instance-wide list endpoint /workspaces/list_as_superadmin exists in the API and SDK but wasn't wired into the CLI.
• This made CI tooling that wants to "create workspace if it doesn't exist" awkward: there was no way to enumerate workspaces beyond the calling user's memberships, and the UI button "List all workspaces as superadmin" had no CLI equivalent.
• Adds --as-superadmin to list-remote. When set, calls listWorkspacesAsSuperAdmin (paginated, 100 per page until exhausted) and renders id / name / owner / fork-of. Falls through to the existing per-user path otherwise.

Note: for the CI "create-if-missing" use case, wmill workspace add --create is already idempotent and usually the right primitive — this flag is for when you actually need to enumerate (audit, drift detection, etc.).

Test plan

• wmill workspace list-remote --as-superadmin --base-url ... --token <superadmin-token> lists every workspace on the instance
• Same command with a non-superadmin token returns the expected 403 error
• wmill workspace list-remote (no flag) still shows the user-scoped list and Logged in as: line
• Pagination works on instances with >100 workspaces (loop terminates, no duplicates)

🤖 Generated with Claude Code

---

Summary by cubic

Adds a new --as-superadmin flag to the wmill workspace list-remote command so superadmins can list every workspace on an instance. Also regenerates CLI prompts and documents the regen step to keep agent-facing docs in sync.

• New Features
  • --as-superadmin uses listWorkspacesAsSuperAdmin with pagination (100/page) until all are fetched.
  • Outputs a table with id, name, owner, and fork of (when present); shows remote and total count with a "(superadmin)" tag.
  • Requires a superadmin/devops token; default behavior is unchanged when the flag is not set.
  • Regenerated auto-generated CLI docs (system_prompts/*, cli/src/guidance/skills.gen.ts) and added an AGENTS.md note to run python system_prompts/generate.py after CLI changes.

^{Written for commit 34eea98. Summary will update on new commits.}

[cloudflare-workers-and-pages]

Deploying windmill with    Cloudflare Pages

Latest commit:	34eea98
Status:	✅  Deploy successful!
Preview URL:	https://775104c1.windmill.pages.dev
Branch Preview URL:	https://cli-list-remote-as-superadmi.windmill.pages.dev

View logs

[claude]

Claude finished @rubenfiszel's task in 2m 9s —— View job

---

PR review

Good to merge — small, focused change; pagination matches the established CLI pattern (cf. cli/src/commands/user/user.ts:44-52 which also paginates listUsersAsSuperAdmin the same way) and the SDK call is identical to existing usage in cli/src/commands/instance/instance.ts:353-356.

Findings

None at P0/P1.

Optional notes (not worth blocking):

• The backend list_workspaces_as_super_admin SQL (backend/windmill-api-workspaces/src/workspaces.rs:3563-3578) uses LIMIT/OFFSET with no ORDER BY, so concurrent inserts/deletes during pagination could in theory duplicate or skip rows. This is pre-existing (also affects instance.ts's perPage: 1000 single-shot call), not something this PR introduces. Worth a follow-up backend fix at some point, but out of scope here.
• For instances with many thousands of workspaces, the loop runs silently — a single log.info per page or after the last page would be a nice-to-have, but again the existing user/script/app paginators don't do this either, so consistency wins.

AGENTS.md compliance

No violations. No frontend or Rust code touched, so the svelte-frontend / rust-backend skill rules don't apply. The CLI change follows existing conventions in the same file.

Test coverage

CLI command — no automated test infrastructure exists for these CLI subcommands in the repo, so no new tests are expected. The PR description's test plan covers the relevant manual scenarios.

Manual verification before merge. The four checkboxes in the PR description are the right ones — exercise wmill workspace list-remote --as-superadmin with a superadmin token (table renders, total reported), then with a non-superadmin token (expect 403), then list-remote without the flag (unchanged behavior incl. Logged in as:), and finally on an instance with >100 workspaces to confirm the page loop terminates and totals are correct.

[cubic-dev-ai]

No issues found across 6 files

[github-actions]

I've now thoroughly reviewed the diff, the API handler, the SDK function, and surrounding code patterns. Here's my assessment:

Pi Review

Good to merge

This is a clean, focused change adding an --as-superadmin flag to wmill workspace list-remote. The implementation follows existing patterns closely: the same Table rendering style, the same parent_workspace_id handling, and the same column logic.

Key points verified:

• No auth bypass: The backend enforces require_devops_role in list_workspaces_as_super_admin (line 3559 of workspaces.rs). A non-superadmin token returns 403 regardless of the CLI flag.
• Pagination is correct: perPage: 100 with a while(true) loop that breaks when batch.length < perPage — handles >100 workspaces without infinite loop or data loss.
• SDK function exists and is used elsewhere: Same wmill.listWorkspacesAsSuperAdmin is already called in instance.ts (lines 353 and 499).
• Type annotation: const all: Awaited<ReturnType<typeof wmill.listWorkspacesAsSuperAdmin>> = [] correctly types the accumulator array.
• Consistent output format: Same Table builder, same Remote: line, same parent_workspace_id ?? "-" null handling. The owner column (instead of username) matches the superadmin endpoint's response shape.
• No half-finished abstractions: The feature is complete; the flag, option definition, and handler logic are all wired together.

Test coverage

CLI — the codebase does not generally have automated tests for CLI command handlers. No tests expected for this change.

Manual verification

• Run wmill workspace list-remote --as-superadmin --base-url ... --token <superadmin-token> on an instance with workspaces — expect a bordered table with id/name/owner columns, then Remote: and Total workspaces: N (superadmin) lines.
• Same command with a non-superadmin token — expect a 403 HTTP error from the API.
• Run wmill workspace list-remote without the flag — expect the original user-scoped output including Logged in as: line (unchanged behavior).
• On an instance with a forked workspace, verify the fork of column appears and shows the parent workspace ID.

[github-actions]

Codex Review

Good to merge

No findings. Checked the CLI diff, root AGENTS.md, SDK pagination shape, and the backend superadmin workspace handler.

Test coverage

CLI-only change; no backend/frontend/CI automated test requirement applies directly here.

Manual verification should cover wmill workspace list-remote --as-superadmin with a superadmin/devops token, the same command with a non-superadmin token returning 403, default list-remote behavior without the flag, and an instance with more than 100 workspaces to confirm pagination.

[github-actions]

I've now reviewed the full diff, the backend handler, the SDK usage in instance.ts, and the AGENTS.md compliance. Here's my assessment:

Pi Review

Good to merge

This is a clean, focused change adding --as-superadmin to wmill workspace list-remote. Auth is enforced server-side by require_devops_role (line 3559 of workspaces.rs), pagination is correct (perPage: 100 loop, breaks when batch.length < perPage), and the implementation follows existing CLI patterns exactly — same Table renderer, same parent_workspace_id ?? "-" null handling, same setClient/resolveWorkspace client setup. The PR also includes regenerated CLI prompts (system_prompts/auto-generated/, cli/src/guidance/skills.gen.ts) and documents the regen step in AGENTS.md, per the rule added in the same commit.

AGENTS.md compliance

No violations. The CLI change follows existing conventions and the regeneration rule is satisfied.

Test coverage

CLI command — the codebase does not have automated test infrastructure for CLI subcommand handlers. No new tests are expected.

Manual verification

The four checkboxes in the PR description are the right ones:

• wmill workspace list-remote --as-superadmin with a superadmin token — expect a bordered table with id/name/owner columns, then Remote: and Total workspaces: N (superadmin).
• Same command with a non-superadmin token — expect a 403 HTTP error (enforced by require_devops_role server-side).
• wmill workspace list-remote without the flag — expect the unchanged original output including Logged in as:.
• On an instance with >100 workspaces — confirm the page loop terminates and the total count is correct, with no duplicates or gaps.