embedded-postgres backend: 4 issues prevent `mem init` from working on darwin-arm64

[lucasygu]

Summary

On a fresh mem init with the default embedded-postgres backend, four separate issues prevented the memory store from coming up. After local patches, mem doctor passes all 7 checks. Reporting all four because each is independently filable.

Environment

• @withone/cli 1.43.4 (installed via npm i -g)
• macOS 25.3.0 (darwin-arm64)
• Node v24.9.0 (nvm)
• Bundled pgserve (v2.6.x judging by the wrapper code) at node_modules/pgserve/
• Bundled @embedded-postgres/darwin-arm64 18.3.0-beta.17

Repro

one --agent mem init --backend embedded-postgres --embedding none -y --force
# → {"status":"warmup_failed","error":"pgserve did not start listening on 127.0.0.1:5434 within 30s. ..."}

---

Issue 1 — pgserve invoked without a subcommand → silent help-banner exit

Where: dist/chunk-IAFQVFCB.js, function ensureRunning(cfg) around the const args = [...] declaration.

What:

const args = [
  "--data", clusterDir,
  "--port", String(cfg.port),
  "--host", cfg.host,
  "--log", cfg.logLevel,
  "--no-stats"
];
const child = spawn(process.execPath, [bin, ...args], { ... });

pgserve-wrapper.cjs (v2.4+, comment "B4 (v2.6.1): unknown-verb guard") expects a subcommand like postmaster, serve, or one of the install verbs. The unknown-verb guard explicitly bypasses anything starting with -, so --data ... falls through to postgres-server.js, which treats no-subcommand as "print help and exit 0." Plugin then times out at 30s waiting for the listener.

Fix: prepend "postmaster" to args.

const args = [
  "postmaster",
  "--data", clusterDir,
  ...
];

---

Issue 2 — pgserve postmaster rejects --host and --no-stats

Where: same args list.

What: pgserve postmaster --help shows the only accepted options are --port, --data, --socket-dir, --log, --ram, --pgvector, --help. Passing --host or --no-stats produces:

pgserve postmaster: unknown option "--host"

The postmaster binds 127.0.0.1 unconditionally, so --host is unneeded. --no-stats is not implemented in postmaster mode.

Fix: remove --host, cfg.host, --no-stats from the args array. After Issue 1 + 2 fixes, pgserve starts in ~1.3s.

---

Issue 3 — pg_hba.conf defaults to TCP password; plugin connects without a password

Where: after pgserve spawns the cluster, pg_hba.conf ships as:

host    all   all   127.0.0.1/32   password
host    all   all   ::1/128        password

The mem backend connects over TCP to 127.0.0.1:5434 with no password configured for that cluster. Postgres rejects with empty password returned by client.

Options:

• Switch the bundled cluster's pg_hba.conf to trust for localhost (the cluster only binds 127.0.0.1 anyway, so the security delta is minimal).
• OR connect via the Unix socket (which has local all all trust by default).
• OR have the plugin generate a password and persist it.

Workaround: edit ~/.one/pg/cluster/pg_hba.conf manually, change password to trust for 127.0.0.1/32 and ::1/128, then re-run.

---

Issue 4 — Plugin doesn't auto-create the one_mem database

Where: after Issues 1–3 are resolved, the next error is:

{"status":"warmup_failed","error":"database \"one_mem\" does not exist"}

Pgserve's help describes "True concurrent connections, zero config, auto-provision databases" — but the plugin appears to connect directly to one_mem without first creating it. The postgres superuser database exists, so the obvious fix is: connect to postgres, CREATE DATABASE one_mem, then reconnect to one_mem for schema application.

Workaround (until fixed in the plugin):

node -e "
const { Client } = require('@withone/cli/node_modules/pg');
const c = new Client({ host: '127.0.0.1', port: 5434, user: 'postgres', database: 'postgres' });
c.connect().then(async () => {
  await c.query('CREATE DATABASE one_mem');
  await c.end();
});
"

After this, mem init succeeds and mem doctor reports 7/7 OK.

---

Repro after all four patches

$ one --agent mem doctor
{
  ok: True,
  checks: [
    [OK] memory config exists — backend=embedded-postgres,
    [OK] backend plugin "embedded-postgres" resolves,
    [OK] backend opens and applies schema,
    [OK] schema version matches — 2.1.0,
    [OK] stats query works — 0 records,
    [OK] embedding provider — disabled (none),
    [OK] capability ↔ config consistent
  ]
}

Happy to send a PR for Issues 1 + 2 (the spawn args fix) if useful — that one is mechanical and unblocks the other failure modes. Issues 3 + 4 deserve a design call (auth strategy, DB-provisioning flow).