fix: bootstrap PostgreSQL without a working service manager (#823)

[GG-O-BP]

What & why

Closes #823.

mxcli run --ensure-db only knew service and a non-working Debian pg_ctlcluster placeholder. On Arch neither produced a server, so bootstrap failed even though the portable initdb, pg_ctl, and psql tools were available.

Fix

• Try service postgresql start with a bounded readiness probe, then fall back to a user-owned cluster under ~/.mxcli/postgres when no service becomes ready. The unusable pg_ctlcluster -- start placeholder is removed.
• Before fallback, check whether the requested TCP port is already owned. A service-started PostgreSQL still in recovery is left to the authoritative 20-second readiness wait instead of racing a second cluster against it.
• Initialize TCP authentication with SCRAM and keep password-free superuser provisioning only on the private Unix socket. Existing socket directories are explicitly tightened to 0700.
• Persist listen_addresses, port, unix_socket_directories, and unix_socket_permissions = 0700 in postgresql.conf; a plain later pg_ctl -D ... start therefore preserves the safe endpoint without mxcli-only runtime flags.
• Reuse an initialized/running cluster only when both its live port and socket directory match. Refuse pre-review clusters that still contain host-trust authentication and provide a stop/remove/recreate path.
• Normalize and validate ports and empty hosts, surface service diagnostics and the server-log path, and keep remote hosts check-only.
• Retain sudo -u postgres psql for system clusters without prompting. It uses the distribution's peer-authenticated default Unix socket at the exact requested port, rather than forcing TCP where changing the OS user supplies no database password. Inherited PGHOST/PGHOSTADDR/PGSERVICE values cannot redirect that path.

Tests

Focused command-stub regressions cover service readiness, the occupied-port race, the removed placeholder, first/repeated/running starts, port and socket mismatches, existing-directory permissions, persistent and idempotent configuration, legacy host trust, authentication arguments, superuser resolution, validation, and actionable failures.

The system-cluster regression models a Debian-style setup: the sudo probe succeeds only when -h is absent (Unix socket/peer auth) and the requested non-default port is still present. It also verifies that libpq target environment overrides are removed.

Validation completed on the rebased 18b133a1 tree:

• make build
• make test
• make lint-go
• go test ./cmd/mxcli/docker -count=1
• targeted go test -race for the changed database paths
• Windows/macOS amd64+arm64 test-binary compilation for the changed package
• make check-mdl and both skill/docs MDL-block checks
• mdbook build docs-site
• cross-platform tunnel dependency check
• git diff --check

The unchanged user-owned-cluster path was previously verified against real PostgreSQL 18.x for bootstrap, app login, repeat provisioning, socket/file permissions, plain pg_ctl restart, reconnect, SCRAM verifier, special-character password transport, and legacy-host-trust refusal.

Docs and scope

Updated only the implementation, its focused tests, the two runtime call sites, CLI help, run-local skill/docs, CHANGELOG, and the final fix-issue table row: nine files, one concern, one commit on current main. No MDL fixture is applicable because this change has no MDL surface.

[ako]

Review

Sound fix, no blockers. Three things I'd want changed before merge, all localized to startLocalPostgres/startUserCluster.

What I verified — applied the two Go files to current main in a throwaway worktree (they apply cleanly):

• go vet ./cmd/mxcli/docker clean; all 12 new subtests pass in 0.5 s.
• The reported Arch path is genuinely fixed: neither service nor pg_ctlcluster is on PATH, both LookPath calls skip, and the fallback runs immediately.

---

Moderate

1. The fallback multiplies the timeout by the number of service attempts — confirmed, not theoretical.

Moving waitPGReady inside the attempts loop means every attempt pays a full 20 s. Instrumented with a scaled-down serviceReadyTimeout, counting probe invocations:

service → isready → pg_ctlcluster → isready → initdb → pg_ctl_start
ready-waits paid = 2   (at the real timeout: 40 s)

Worst case is now 20 + 20 (services) + 30 (pg_ctl -w -t 30) + 20 (EnsureDatabase's own waitPGReady) ≈ 90 s before an error surfaces, against ~20 s before. Worse, 20 s of that is spent on {"pg_ctlcluster", "--", "start"} — the entry whose own comment admits the args are a placeholder and cannot work.

Fix: drop the pg_ctlcluster placeholder, and probe inside the loop with a short timeout (2–3 s), keeping the single long waitPGReady where it already is in EnsureDatabase.

2. --auth-host=trust disables authentication on 127.0.0.1:5432.

Confirmed via the initdb args: -U postgres --auth-local=trust --auth-host=trust. The comment justifies it with "the server binds only the local interface", but loopback is not an access control on a multi-user host: any local account becomes the postgres superuser, and PostgreSQL superuser gets COPY … PROGRAM, i.e. shell as the developer's OS user.

Fix: the socket directory is already 0700 (verified — drwx------), so trust over the socket is genuinely safe. Keep --auth-local=trust, set --auth-host=scram-sha-256, and point superuser.psql's non-sudo branch at -h <sockDir> instead of -h 127.0.0.1. The app role already has a password, so canConnectDB over TCP still works unchanged.

3. The fix-issue.md row lands mid-table.

The hunk inserts at line ~322; on current main that table ends at line 429. .gitattributes sets merge=union on that file — which keeps both sides of a conflicting hunk, so a mid-table insert against a moved table interleaves and merges "cleanly" while being wrong. The branch predates the append-at-the-end rule.

Fix: rebase and move the row to the end of the table.

Minor

• --db-host ":5432" produces a malformed server option. isLocalHost("") is true, so an empty host reaches -o "-h -p 5432 -k …"; pg_ctl splits on whitespace and postmaster reads -p as the value of -h. Confirmed in a probe. Obscure (the default fills in 127.0.0.1:5432), but a one-line guard in startUserCluster would close it.
• pg_ctl status == 0 returns early without checking the port. A cluster left running from an earlier --ensure-db --db-port 5433 satisfies status, then EnsureDatabase burns 20 s on waitPGReady against the wrong port and reports a confusing failure. Reading the port from line 4 of postmaster.pid would make it precise.
• The server log path isn't in the error. startUserCluster writes -l ~/.mxcli/postgres/server.log, but the failure message carries only pg_ctl's stdout. Naming the log file makes the error self-service.
• Service-manager output is now fully discarded (_ = exec.Command(…).Run()). If service postgresql start explains itself, the user instead sees an initdb error from two steps later.

Checklist

Bug-fix requirements met: symptom row added, tests accompany the fix, .claude/skills/mendix/run-local.md (the sync source, not the regenerated cmd/mxcli/skills/ embed dir — correct choice), the docs-site page, and the CHANGELOG all updated. Single concern, single commit.

The mdl-examples/bug-tests/ requirement is the only apparent checklist gap and is correctly N/A — there's no MDL surface here and nothing for Studio Pro to validate. The backend-abstraction, grammar, and syntax/features_*.go sections don't apply either.

Thanks for the thorough stub-test coverage — the ready/non-ready service split and the idempotency cases are exactly the right seams to pin down.

🤖 Generated with Claude Code

[GG-O-BP]

Thanks for the thorough review, @ako — all seven points are addressed. Rebased onto main (the branch was CONFLICTING; it's now a clean single commit) and everything stays localized to startLocalPostgres/startUserCluster/resolveSuperuser.

Moderate

1. Timeout multiplication + dead pg_ctlcluster. Dropped the pg_ctlcluster placeholder entirely, and each service attempt now pays only a short serviceReadyTimeout (3 s, down from 20 s) — the single authoritative 20 s wait stays in EnsureDatabase. New TestStartLocalPostgres_NeverRunsPgCtlCluster asserts the entry can never run even when it's on PATH.
2. --auth-host=trust on loopback TCP. initdb now uses --auth-local=trust --auth-host=scram-sha-256, and the direct superuser connects over the 0700 socket dir (-h <sockDir>) instead of -h 127.0.0.1. So the passwordless superuser can only reach itself over the private socket; loopback TCP is no longer an authentication bypass. canConnectDB (app role, has a password) still works over TCP unchanged. Covered by TestStartUserCluster_InitdbAuthArgs and TestResolveSuperuser_PrefersClusterSocket.
3. fix-issue.md row mid-table. Rebased; the row is now appended at the very end of the symptom table (one-line diff).

Minor

• Empty --db-host (":5432"). Normalised to 127.0.0.1 in both EnsureDatabase and startUserCluster, so the server option is well-formed. TestStartUserCluster_EmptyHostNormalised reproduces the old malformed -h -p 5432 and asserts the fix.
• pg_ctl status==0 ignoring the port. New clusterStatus reads the port from line 4 of postmaster.pid; a running cluster is reused only when its port matches, otherwise it fails fast with an actionable message instead of burning the readiness wait on the wrong port. TestStartUserCluster_RunningPortGuard covers both branches.
• Server log path missing from the error. The start-failure error now names ~/.mxcli/postgres/server.log (TestStartUserCluster_StartErrorNamesLog).
• Discarded service-manager output. Captured and appended to the fallback error when the fallback then fails (TestStartLocalPostgres_SurfacesServiceOutput).

Each new test was proven to fail on the un-fixed code (reverted each change in a throwaway worktree and watched the matching test fail with the reported symptom). make vet, go build ./..., and go test ./cmd/mxcli/docker -count=1 are green.

[ako]

Review (round 2)

Thanks — I re-verified all seven points from the previous round and they are all addressed. Three new issues, one of which is a regression introduced by the fix for point 1.

What I verified — merged the branch into current main in a throwaway worktree:

• go vet ./cmd/mxcli/docker clean; all 20 subtests pass, on the branch and merged onto main.
• The fix-issue.md row is genuinely last now: 229 rows on main → 230 merged, no interleave.

Prior point	Status
Timeout multiplication	Fixed — serviceReadyTimeout = 3s inside the loop, the 20 s wait stays in EnsureDatabase. Worst case ~53 s, down from ~90 s
pg_ctlcluster placeholder	Removed, with TestStartLocalPostgres_NeverRunsPgCtlCluster pinning it
--auth-host=trust	Now scram-sha-256; superuser goes over the private socket. Test asserts both
fix-issue.md mid-table	Verified last, merges cleanly against current main
--db-host ":5432"	Normalised in both EnsureDatabase and startUserCluster
pg_ctl status port	postmaster.pid line 4 compared; mismatch errors immediately
Log path / service diagnostics	Both in the error now

---

Blocker

1. The short probe turns "slow but working" into a hard failure.

startLocalPostgres falls through to startUserCluster unconditionally once the 3 s probe expires. The old code returned nil after running the service manager and let EnsureDatabase's 20 s wait decide, so this is a regression. Confirmed with a stub whose pg_isready succeeds on the 9th probe (~4 s), i.e. a service-started server that comes up just after the short probe gives up:

err=<nil> calls="service\ninitdb\npg_ctl_start\n"

Against real PostgreSQL that pg_ctl start binds an already-occupied 5432 → could not bind IPv4 address … Address already in use → EnsureDatabase fails with a confusing error, and a stray ~40 MB cluster is left in ~/.mxcli/postgres.

The likely trigger is not exotic: crash recovery after a reaped container. PostgreSQL refuses connections while replaying WAL (the database system is starting up, pg_isready → not ready), easily past 3 s — and that is exactly the path mxcli run --local --setup --ensure-db takes from the SessionStart hook after a devcontainer is killed.

Fix — in startLocalPostgres, before the fallback:

// Something already owns the port (e.g. a service-started server still in
// crash recovery). Never initdb a competitor — EnsureDatabase's authoritative
// 20s wait decides.
if pingTCP(net.JoinHostPort(host, port), time.Second) == nil {
    return nil
}

A short probe should answer "should I look further?", never "should I build a competitor?".

Moderate

2. os.MkdirAll(sockDir, 0o700) does not tighten an already-existing directory.

MkdirAll is a no-op on an existing path — the mode argument is ignored. Pre-created the dir at 0755 and ran startUserCluster:

sock dir mode after startUserCluster: -rwxr-xr-x

That directory mode is the entire access control behind --auth-local=trust; at 0755 any local account connects as the postgres superuser, which is the vulnerability the previous round closed, reached by a different route.

Fix: os.Chmod(sockDir, 0o700) after MkdirAll (or Stat-and-refuse). The test should pre-create the dir at 0755 and assert it was tightened, rather than only exercising the fresh-dir path.

3. The 0700-socket control lives only in a command-line flag, not in the cluster.

-k <sockDir> is passed through pg_ctl -o, so the hardening holds only for a server mxcli starts. Any other start reverts to the build's compiled unix_socket_directories (/tmp on many builds, world-writable), and --auth-local=trust applies to that socket too. The code nudges users down exactly that path — the mismatched-port error says stop it with pg_ctl -D … stop, and the natural next step is a plain pg_ctl … start.

Fix: persist it in the cluster's own config — write unix_socket_directories, listen_addresses, and port into postgresql.conf after initdb (or initdb -c unix_socket_directories=… on PG 15+), so the property survives a start mxcli did not perform.

Minor

• No upgrade path off the earlier revision's cluster. A data directory initialized by the earlier --auth-host=trust commit is reused silently — PG_VERSION is the only check — so the hardening does not apply retroactively. That includes anyone who tested the earlier build. A CHANGELOG line ("delete ~/.mxcli/postgres if you ran the pre-review build") or a pg_hba.conf check on reuse would close it.
• _ = logPath in TestStartLocalPostgres_SurfacesServiceOutput is a leftover; dir, _ := newStubPATH(t) reads better.
• The docs don't mention that the cluster persists across sessions, where server.log lives, or how to stop/remove it. pg_ctl -D ~/.mxcli/postgres/data stop currently appears only inside an error string.
• The branch is ~24 commits behind main and CHANGELOG.md conflicts on merge (fix-issue.md merges cleanly). Worth a rebase before merging.

Checklist

Bug-fix requirements met: symptom row appended at the end of the table, tests accompany the fix, the sync source skill (.claude/skills/mendix/run-local.md, not the regenerated embed dir), the docs-site page, and the CHANGELOG all updated. Single concern, single commit. mdl-examples/bug-tests/ remains correctly N/A — no MDL surface. The --ensure-db flag help needed no change (it never mentioned sudo).

The stub-test coverage is a real strength here — the port-guard and idempotency cases in particular made the two remaining defects cheap to demonstrate rather than argue about.

🤖 Generated with Claude Code

[GG-O-BP]

Thanks, @ako — round 2 is fully addressed in 8efbd329.

Blocker

1. Slow service startup no longer creates a competitor. After the short readiness probe, startLocalPostgres now checks the requested endpoint with pingTCP(net.JoinHostPort(host, port), time.Second). If anything already owns it, control returns to the authoritative 20-second wait in EnsureDatabase; initdb and pg_ctl start are not called. TestStartLocalPostgres_OccupiedPortSkipsFallback uses a real TCP listener plus a failing pg_isready stub and proved the old branch took the fallback before the guard was added.

Moderate

2. An existing socket directory is tightened. MkdirAll is followed by explicit os.Chmod(sockDir, 0o700). The regression pre-creates it as 0755 and asserts 0700 afterward.

3. The endpoint is now cluster configuration, not a one-shot pg_ctl -o flag. A single idempotent managed block at the end of postgresql.conf persists listen_addresses, port, unix_socket_directories, and unix_socket_permissions = 0700; pg_ctl start no longer passes -o. The test asserts the settings, mode 0600, one managed block, and byte-stable repeat application. I also verified this against PostgreSQL 18.4 by stopping the bootstrapped cluster, restarting it with plain pg_ctl -D ... -w -l ... start, and reconnecting as the app role.

Minor and follow-through

• Pre-review host-trust clusters are detected from pg_hba.conf and refused with an explicit stop/remove/rerun path; CHANGELOG also calls out that cleanup.
• Removed the _ = logPath leftover.
• Both run-local docs now explain persistence, server.log, stopping, and destructive removal.
• Rebuilt the branch as exactly one commit on current main; the PR is mergeable with no CHANGELOG conflict.
• Also validate/canonicalize the port before writing PostgreSQL configuration and require both the live port and private socket directory to match before reusing a running cluster.

The final tree passed make build, make vet, make test, package tests, targeted race tests, git diff --check, and the PostgreSQL 18.4 end-to-end bootstrap/restart checks above.

[GG-O-BP]

Final self-audit amended the single commit to 01cd6c59 (the round-2 fixes described above are unchanged). Two narrow edge-case corrections were included before handoff: endpoint validation now precedes the persisted-config write so a rejected running-cluster request cannot alter its next restart, and fallback tests allocate an unused loopback port instead of assuming CI port 5432 is free. The exact final commit then passed make build, make vet, make test, targeted race tests, and git diff --check.

[ako]

Confirmed — and one of the six is weaker than it first looked, which changed what I'd say. Here's the text to paste:

Reviewed by fetching the PR head and reading the full diff locally (go vet clean, the new tests pass in ~2.5s).

The design is sound and the security work is careful — private 0700 socket dir, scram on loopback TCP, legacy host-trust rejection, running-cluster port and socket guards, atomic conf writes with an idempotent managed block. Six things below; the first three I verified directly in the code, the rest are weaker or unconfirmed and flagged as such.

---

1. superuser.psql sudo branch ignores the struct's host and port — provisions the wrong cluster

cmd/mxcli/docker/ensuredb.go:492

func (s superuser) psql(args ...string) *exec.Cmd {
	if s.sudo {
		return exec.Command("sudo",
			append([]string{"-u", "postgres", "psql", "-v", "ON_ERROR_STOP=1"}, args...)...)
	}
	// ... non-sudo branch uses s.host / s.port

The struct carries host, port and the non-sudo branch honours them, but the sudo branch passes neither -h nor -p, so psql falls back to the default socket. With --db-host 127.0.0.1:5433 and a system cluster on 5432, the role and database are created on 5432 and --ensure-db then fails with "provisioned PostgreSQL but still cannot connect" — having silently written to a cluster the user didn't name.

2. Same branch has no -w (or -n) — hangs on password-protected sudo

[cmd/mxcli/docker/ensuredb.go:528](https://github.com/ako/mxcli/blob/claude/widget-sync-modelsdk-rawunits/cmd/mxcli/docker/ensuredb.go#L528)

The non-sudo branch's own comment states the rule:

-w never prompts, so probing an unrelated password-protected system cluster fails fast instead of hanging.

The sudo branch is the one path that doesn't follow it. Where sudo needs a password it blocks on /dev/tty indefinitely, in a command users run non-interactively.

3. EnsureDatabase takes DBConfig by value — the normalized host never reaches the runtime

cmd/mxcli/docker/ensuredb.go:79,98

func EnsureDatabase(db DBConfig, w io.Writer) error {
	...
	if host == "" {
		host = "127.0.0.1"
		db.Host = net.JoinHostPort(host, port)   // local copy only
	}

localboot.go:283 then sends "DatabaseHost": o.DB.Host to the runtime. With --db-host :5432 mxcli prints "Database ready … at 127.0.0.1:5432" while the runtime is handed ":5432" — the message and the behaviour disagree.

4. --auth-host=scram-sha-256 + plain CREATE ROLE … PASSWORD on PostgreSQL ≤13

[cmd/mxcli/docker/ensuredb.go:394](https://github.com/ako/mxcli/blob/claude/widget-sync-modelsdk-rawunits/cmd/mxcli/docker/ensuredb.go#L394) — not reproduced, worth confirming. On servers where password_encryption still defaults to md5, the role is stored md5 while pg_hba demands scram, and the app role is rejected with "does not have a valid SCRAM secret" — recoverable only by hand-editing pg_hba.conf. A SET password_encryption = 'scram-sha-256' before the CREATE ROLE would make it version-independent.

5. Ignoring the service manager's exit code — narrower than it first appears

[cmd/mxcli/docker/ensuredb.go:177](https://github.com/ako/mxcli/blob/claude/widget-sync-modelsdk-rawunits/cmd/mxcli/docker/ensuredb.go#L177) — I'd downgrade this one. My first read was that dropping the exit code in favour of a 3s probe risks initdb-ing a competing cluster, but the code immediately below anticipates exactly that:

// A service-started server may own the port while crash recovery still makes
// pg_isready report "not ready". Never initialize a competitor in that case
if pingTCP(net.JoinHostPort(host, port), time.Second) == nil {

So the remaining window is only a postmaster that has neither become ready nor bound its port within the probe — much smaller than I initially thought, and arguably acceptable. Raising it only so the reasoning is on the record.

6. IPv6 port-mismatch hint suggests a --db-host the tool rejects

[cmd/mxcli/docker/ensuredb.go:420](https://github.com/ako/mxcli/blob/claude/widget-sync-modelsdk-rawunits/cmd/mxcli/docker/ensuredb.go#L420) — the hint is built with net.JoinHostPort(host, livePort), which brackets IPv6 literals, but the parser is:

func splitHostPort(hostPort string) (host, port string) {
	if i := strings.LastIndexByte(hostPort, ':'); i >= 0 {
		return hostPort[:i], hostPort[i+1:]
	}

LastIndexByte on [::1]:5433 yields host [::1] with the brackets attached, which won't match a local-host check. Following the tool's own suggestion fails. Cosmetic unless someone runs on IPv6 loopback.

[GG-O-BP]

Addressed all six follow-ups in 2afab5c8, rebased onto current main (1421f11f).

1. Exact sudo target: the sudo path now passes the requested -h and -p (plus explicit user/database), so it cannot silently provision the default cluster instead.
2. No prompts: sudo uses -n; every provisioning/probe psql invocation uses -w. I also added -X so a user or postgres account's psqlrc cannot alter the non-interactive session.
3. Runtime endpoint propagation: EnsureDatabase now accepts *DBConfig, canonicalizes Host once, and returns that exact value to both local runtime call sites. A regression test proves :5432 reaches runtime configuration as 127.0.0.1:5432.
4. SCRAM on older defaults: role creation sets password_encryption = 'scram-sha-256' for its session before assigning the password. This leaves global server configuration untouched.
5. Service exit-code point: retained readiness as the authority, together with the existing exact-port TCP guard before fallback. Tests cover a non-zero service exit that nevertheless becomes ready, an ineffective service, and an occupied-but-not-ready port that must suppress initdb.
6. IPv6 round trip: endpoint parsing now handles canonical bracketed IPv6 first ([::1]:5433), while preserving the prior unbracketed ::1:5433 compatibility form. Canonical output uses net.JoinHostPort, and the CLI/docs now show bracketed IPv6.

Additional hardening found during the pass:

• A failed non-local endpoint now returns before any local direct/sudo provisioning attempt.
• Password-bearing role DDL is piped to psql over stdin rather than exposed in process arguments, with standard_conforming_strings fixed for the session.
• Added exact command-argument, endpoint-propagation, remote-refusal, password-transport, IPv6, SCRAM, repeated-start, permissions, and running-cluster regression coverage.

Validation performed:

• make build
• make test
• make lint-go
• focused go test -race for the database bootstrap paths
• full integration-tag suite for ./cmd/mxcli/docker (105.362s)
• isolated real PostgreSQL 18.6 bootstrap/restart/reconnect checks, including a special-character password and a SCRAM verifier check
• all checkable MDL fixtures and skill/docs MDL blocks
• Windows/macOS amd64+arm64 cross-compilation of the changed package
• govulncheck ./... (0 reachable vulnerabilities)

One transparent local-environment note: a whole-repository make test-integration run exhausted the 30-minute package timeout in unrelated mdl/executor work under the available CPU limit; the test named at timeout passed alone in 18.46s. That run also hit the existing random-port IPv6 owner-test collision once; the test then passed 20 consecutive repetitions, and the full changed-package integration suite passed. No integration failure reproduced in the code changed by this PR.

[GG-O-BP]

Follow-up audit: one system-cluster blocker before merge

I re-checked 2afab5c8 against the current upstream main (29cf21c7) in a throwaway clone. The Arch/user-owned-cluster design still looks sound, and the synthesized tree passes:

• make build, make test, and make lint-go
• focused package tests, targeted race tests, and go vet
• make check-mdl plus the skill/docs MDL-block checks
• mdbook build docs-site
• git diff --check and the cross-platform tunnel dependency check

There is, however, one blocker in the retained system-cluster path.

sudo -u postgres is forced over TCP, so the normal peer-auth path no longer works

superuser.psql builds the sudo command with the same base arguments as the direct connection:

sudo -n -u postgres -- psql ... -w -h 127.0.0.1 -p 5432 -U postgres ...

A numeric -h selects TCP. Changing the OS user to postgres only helps PostgreSQL peer authentication over a Unix-domain socket; it does not authenticate a TCP connection. Debian's pg_createcluster defaults to peer authentication on local Unix sockets and password authentication on TCP. With -w and no supplied postgres password, a normal Debian/Bookworm cluster therefore rejects this probe unless an incidental .pgpass/password setup exists.

That affects the repository's generated Bookworm devcontainer directly: it installs the Debian PostgreSQL server and explicitly relies on sudo -u postgres psql for --ensure-db. The pre-PR implementation omitted -h, so it used the system socket and peer auth. The current argv-only test stubs sudo to exit 0 and asserts the TCP arguments, so it cannot expose the authentication regression.

The sudo path should select the requested system cluster through its Unix socket (while retaining the exact port and sudo -n/psql -w safeguards), with a regression that exercises a default Debian/Bookworm-style peer/socket + password/TCP HBA rather than only checking argv.

Merge/CI state

The PR is also currently CONFLICTING / DIRTY: it is 78 commits behind current main, with the only content overlap in the append-only .claude/skills/fix-issue.md. Local Git's configured union driver resolves that mechanically; the Go files do not overlap upstream changes.

The Build, Test & Lint and Deploy Documentation workflows are still awaiting maintainer approval, so the only completed GitHub check is AI PR Review. There is no formal approving review yet.

I am addressing the system-socket regression, rebasing onto current main, and will re-run validation before updating the branch.

[GG-O-BP]

Addressed the follow-up finding in 18b133a1 and rebased the single commit onto current main (29cf21c7). GitHub no longer reports a content conflict; maintainer review and the repository's CI checks are still outstanding.

• The sudo superuser path no longer passes a numeric -h, so Debian/Ubuntu's normal Unix-socket peer authentication remains usable.
• It still passes the exact requested -p, preventing a request for (for example) port 5544 from silently provisioning the default 5432 cluster.
• Inherited PGHOST, PGHOSTADDR, and PGSERVICE values are removed on that deliberately host-less path so they cannot redirect it back to TCP or another service.
• The regression stub now rejects any sudo invocation containing -h and only accepts the requested non-default port; the argv/environment test pins the same contract.
• CHANGELOG, fix-issue record, commit text, and PR description now describe the socket/port behavior accurately.

Local validation on the exact pushed tree: full build/unit/lint, focused and race database tests, Windows/macOS amd64+arm64 package compilation, all MDL and skill/docs block checks, mdBook, tunnel dependency checks, and git diff --check are green. This is local evidence only; it does not replace maintainer review or the repository's own CI result.

The two ordinary fork workflows were triggered again but remain in action_required awaiting maintainer approval:

• Build, Test & Lint: https://github.com/mendixlabs/mxcli/actions/runs/32800974478
• Deploy Documentation: https://github.com/mendixlabs/mxcli/actions/runs/32800974484

[ako]

Re-reviewed at 18b133a. All six items from the previous round are addressed, and I mutation-checked three of them — reverting each fix makes a test fail, so the guards detect something. go vet clean, ./cmd/mxcli/docker/ green.

Verified individually:

sudo host/port — -p s.port is now unconditional and -h is deliberately omitted for the sudo path to keep peer auth on the system socket. Dropping either makes TestSuperuserPSQL_SudoUsesPeerSocketPortAndNeverPrompts and TestResolveSuperuser/sudo_fallback fail.
Non-interactive — sudo -n + psql -w, caught by the same test.
Endpoint propagation — EnsureDatabase(*DBConfig) sets db.Host = endpoint, and both callers pass &opts.DB before runtimeOptions() snapshots it, so the runtime's DatabaseHost is the endpoint that was actually checked and provisioned. Stubbing the assignment yields ":5432" and fails TestEnsureDatabase_NormalizesHostForCaller.
Competitor guard — replacing the pingTCP check at ensuredb.go:225 with a no-op makes TestStartLocalPostgres_OccupiedPortSkipsFallback fail with service / initdb / pg_ctl_start. The guard is doing real work.
IPv6 — I ran splitHostPort over ::1, [::1]:5432, [::1], ::1:5432, ::, fe80::1, 0:0:0:0:0:0:0:1, 2001:db8::1. All resolve to the right host/port, and the compatibility branch still accepts the historical unbracketed ::1:5432.
SCRAM on pre-14 — session-scoped SET password_encryption, so an administrator's global config is untouched.
The test harness is the strongest part: every external tool is stubbed, unusedTCPPort removes the dependency on 5432 being free on the CI host, and TestStartUserCluster_PersistsSecureConnectionSettings pre-loosens the socket dir to 0755 before asserting 0700 — a real control rather than an assertion that would pass against unfixed code. The byte-stability check on a repeated startUserCluster is a nice touch.

Two non-blocking observations:

1. The service manager's diagnostic is discarded on the success path. serviceDiag is collected in startLocalPostgres but surfaced only when startUserCluster also fails (ensuredb.go:233-238). The common Debian/Ubuntu case is a non-root user with a perfectly good system cluster that is merely stopped: service postgresql start fails with a permission error, the port stays down, and --ensure-db quietly creates a second, independent cluster on the same port. The output says "Initializing user-owned PostgreSQL cluster…", which is honest but doesn't say why the service path was skipped — and the next sudo systemctl start postgresql then hits a port conflict with no visible cause. One fmt.Fprintln(w, …) of serviceDiag before falling back would close that.

2. A missing initdb/pg_ctl reports as a bare exec error. startUserCluster runs initdb without a LookPath pre-check, so on a host with no PostgreSQL installed at all the user gets initializing PostgreSQL cluster in ~/.mxcli/postgres/data: exec: "initdb": executable file not found in $PATH — the same shape as the error mxcli run --ensure-db can't start PostgreSQL on Arch Linux #823 was opened about. A pre-check naming initdb, pg_ctl and psql with "install PostgreSQL" would finish the job. TestStartLocalPostgres_Fallback/missing tools already exercises the path; it just asserts that an error occurred, not what it says.

Neither blocks merge.