Feature Request: `codexbar serve` - Built-in HTTP server for remote access

[NSEvent]

Feature Request: codexbar serve - Built-in HTTP server for remote access

Summary

Add a codexbar serve command that exposes the existing CLI JSON output via a local HTTP server, enabling remote access to usage data from mobile apps, web dashboards, and home automation systems.

Motivation

The CLI already provides excellent JSON output (codexbar usage --format json), but there's no built-in way to access this data remotely. Users currently have to:

• SSH into their machine and run the CLI
• Build custom wrapper scripts
• Set up cron jobs to sync data elsewhere

A built-in server would unlock several use cases:

Use Case	Description
Mobile companion apps	iOS/Android apps to check usage on the go
Web dashboards	Browser-based monitoring for teams or personal use
Home automation	Home Assistant, Grafana, or custom alerting
Linux status bars	Easier integration for Waybar/Polybar modules (mentioned in README)
Team visibility	Slack/Discord bots, shared dashboards

Proposed API

codexbar serve [--port 8080] [--bind 127.0.0.1] [--refresh-interval 60]

Endpoints

GET /usage
GET /usage?provider=claude
GET /usage?provider=all
GET /cost
GET /cost?provider=codex
GET /health

Response format would match existing CLI JSON output exactly, so any tooling built for the CLI works with the server.

Example

# Start server
codexbar serve --port 8080

# From another terminal or device
curl http://localhost:8080/usage?provider=claude

Implementation Notes

• Reuses CodexBarCore for all data fetching (no duplication)
• Could use Swift NIO, Hummingbird, or even basic Network.framework
• Works on both macOS and Linux (CLI already supports Linux)
• Respects existing ~/.codexbar/config.json for provider settings
• Background refresh on configurable interval (default: match app's refresh cadence)
• Optional: --cors flag for browser access

Security Considerations

• Default bind to 127.0.0.1 (localhost only)
• Explicit --bind 0.0.0.0 required for network access
• No authentication by default (trust local network / VPN like Tailscale)
• Optional: --token flag for simple bearer auth

Alternatives Considered

1. Webhook/push mode: Server pushes to configured URL. More complex, requires external endpoint.
2. iCloud sync: Apple-specific, doesn't help Linux users or non-Apple ecosystems.
3. MQTT publishing: Good for home automation but narrower use case.

The HTTP server approach is the most universally useful since HTTP is understood everywhere.

Willingness to Implement

I'm happy to submit a PR for this if there's interest. Wanted to check alignment on the approach before investing time.

---

Questions for maintainers:

1. Any preference on HTTP library (NIO, Hummingbird, or minimal stdlib)?
2. Should it run as a foreground process, or support daemonization?
3. Any concerns about scope or maintenance burden?