fix(cli): ensure first user created via CLI is admin

[geovannewashington]

What changed

The CLI now ensures that the first user created is automatically granted admin privileges, even when the --admin flag is not used.

Why

Previously, admin privileges were only assigned when the --admin flag was explicitly provided. This created an inconsistency with the API setup endpoint, which automatically promotes the first user to admin.

This change aligns the CLI behavior with the API and prevents misconfiguration during initial system setup.

How to test

1. Start the environment with make start
2. Remove the database volume to ensure a clean state
3. Run ./bin/cli user create <username> <password> <email>
4. Run ./bin/cli user list
5. Verify that the created user has the role "admin"

Fixes #6153

[github-actions]

Claude finished @geovannewashington's task in 5m 53s —— View job

---

Code Review Complete

Reviewed 1 file. 1 inline issue posted (1 critical).

The production code logic (Admin: input.Admin || !system.Setup) is correct and properly aligns the CLI with the API's setup behavior. However, the unit tests in cli/services/users_test.go were not updated to reflect the new call order and admin-promotion logic, and will fail.

Summary of test breakage

The SystemGet call was moved from after UserCreate to before it, changing the mock expectations needed. Two existing test cases will fail:

• "fails creates a user" — missing SystemGet mock entirely (will panic on unexpected call)
• "successfully creates a user" — expects Admin: false but the new logic produces Admin: true when Setup is false

See the inline comment for detailed fix instructions.

---

If you've addressed the feedback and want a new review, tag @shellhub-io/admin and a team member can trigger it.

[gustavosbarreto]

/review

[github-actions]

Claude finished @gustavosbarreto's task in 3m 5s —— View job

---

Code Review Complete

Reviewed 2 files. 1 inline issue posted (1 critical).

The production code logic (Admin: input.Admin || !system.Setup) is correct and properly aligns the CLI with the API's setup behavior. However, the test suite still lacks coverage for the Setup: true path — the scenario where a user is created after initial setup and should not be auto-promoted to admin. All existing tests use Setup: false, so a regression removing the guard would go undetected.

---

If you've addressed the feedback and want a new review, tag @shellhub-io/admin and a team member can trigger it.

[gustavosbarreto]

/review

[github-actions]

Claude finished @gustavosbarreto's task in 2m 0s —— View job

---

Code Review Complete

Reviewed 2 files. 1 inline issue posted (1 critical).

The production code logic (Admin: input.Admin || !system.Setup) is correct and properly aligns the CLI with the API's setup behavior. The previous review feedback has been addressed — tests now cover both Setup: false (auto-promote) and Setup: true (no auto-promote) paths.

However, the SystemGet error fallback now has a privilege escalation implication it didn't have before (see inline comment).

---

If you've addressed the feedback and want a new review, tag @shellhub-io/admin and a team member can trigger it.

[gustavosbarreto]

/review

[github-actions]

Claude finished @gustavosbarreto's task in 3m 3s —— View job

---

Code Review Complete

Reviewed 2 files across code quality, security, testing, language patterns, and architecture — no issues found. The code looks good as-is.

The production code logic (Admin: input.Admin || !system.Setup) is correct and properly aligns the CLI with the API's setup behavior. The previous review feedback has been fully addressed:

• Tests now cover both Setup: false (auto-promote first user) and Setup: true (no auto-promote) paths
• The SystemGet error fallback conservatively defaults to Setup: true, preventing unintended privilege escalation during infrastructure failures (as suggested in review build(deps): bump mixin-deep from 1.3.1 to 1.3.2 in /ui #3)

---

If you push additional changes and want a new review, tag @shellhub-io/admin and a team member can trigger it.

View job