buffer-cli: wp-to-buffer-pro parity in the terminal — OAuth, no scrape

buffer-cli is a public Bun + commander CLI (HEAD 778ecaf, 3 commits, ~1892 LOC) with WPZinc-shaped OAuth via localhost:9876 into ~/.buffer-cli. Gaps: no queue.ts, no --from, token refresh TODO, CHANGELOG still Unreleased.

Who

I wanted Buffer scheduling without WordPress and without cookie-scraping CLIs.

For people who already know WPZinc wp-to-buffer-pro and want the same OAuth + config shape outside PHP.

What

I built buffer-cli, public https://github.com/michaelmonetized/buffer-cli. HEAD 778ecaf. 3 commits. 0 stars. Default main. Version 0.1.0 (CHANGELOG still [Unreleased]). CLI only.

Shipped (~1892 LOC): auth, profiles, post, config, tags, info. Bun + commander.

CLI post / profiles

OAuth WPZinc flow

Gateway: Buffer to wpzinc OAuth to localhost:9876 to ~/.buffer-cli. X-Forwarded-Host www.hustlelaunch.com.

Parity: types/config match wp-to-buffer-pro; template tags {title} {url} {excerpt}.

Docs vs shipped

Gaps: no queue.ts; no --from; token refresh TODO; PLAN mostly unchecked; FALLOW postCommand CRAP 1190.

Architecture

Where

Code: https://github.com/michaelmonetized/buffer-cli, public. No live web app.

bun install && bun run src/index.ts

When

2026-02-16. 9b53095 feat: initial implementation (+3097 LOC).

2026-06-22. 95fe1c3 nightly: fallow-gate + REVIEW.md.

2026-06-22. 778ecaf nightly to HEAD.

Commit arc

Why

Buffer's own CLI is gone, and scraping gets you banned. This keeps the WPZinc OAuth + config shape in Bun so agents can schedule without PHP or cookie jars.

Engagement Q: Cut README to match HEAD, or finish queue.ts first?