DevPods turns earbuds into a developer control surface.
The system captures earbud-style events, routes them through a local bridge with explicit policy and approval rules, optionally rewrites spoken responses with OpenClaw, and returns short, ear-safe responses back to the user. Today that loop is proven through a desktop-first bridge and an Android software relay MVP.
Important
Current status: DevPods is a validated software loop with a working Android relay MVP. The bridge, runtime, and Android relay are build-clean, lint-clean, and fully tested. The Android relay now supports a 10-provider mesh covering AirPods/Beats, Samsung Galaxy Buds, Sony, Nothing, Oppo/Realme/OnePlus, generic Bluetooth, MediaSession, Assistant fallback, and BLE GATT battery. Physical device validation is ongoing — MediaSession path is confirmed on realme RMX3990 (Android 16).
Note
The primary CLI name is devpods. The legacy jarvis-earbuds binary is retained as a compatibility alias while internal filenames catch up.
DevPods is not "an AI inside earbuds." The earbuds are the control surface.
The product model is:
Earbud gesture or Android relay event
-> local bridge runtime
-> workspace policy and approval gates
-> developer action or status lookup
-> optional OpenClaw rewrite
-> short spoken response back to the user
That gives you a hands-free interface for developer tasks like quick repo status, CI summaries, approval-gated actions, and short spoken updates without giving away local execution safety.
The current product path is:
Bluetooth earbuds
-> DevPods Relay on Android
-> DevPods Bridge on desktop
-> repo, CI, editor, and policy-backed actions
-> short spoken response back to the earbuds
The desktop simulator and CLI still matter, but they now support the Android-first product path rather than define it.
- Local HTTP bridge with
GET /healthandPOST /events - Shared bridge runtime used by both server and one-shot CLI commands
- Deny-by-default workspace allowlist and approval model
- Session state, audit logging, and output redaction
- Local Jarvis runtime for repo status, diff, CI, file open, test runs, commit messaging, push, deploy, delete, and revert flows
local,http, andgateway-clientruntime modes- Adaptive rewrite policy with foreground and background budgets
- Health reporting for rewrite policy, gateway state, and readiness
- Real sandboxed and managed OpenClaw validation surfaces
- Foreground relay service
- Multi-tab product UI shell (Home, Activity, Device, Help, Developer mode) with onboarding, setup wizard, QR pairing, and diagnostic export
- Speech recognition and TTS adapters
- 10-provider earbud mesh with priority-based fallback
- Explicit approval, reject, and cancel actions
- Installed-app emulator validation script for the debug APK
The Android relay implements a layered provider system for broad physical earbud compatibility:
| Priority | Provider | Brands | Key mechanism |
|---|---|---|---|
| 1 | apple_airpods |
AirPods, Beats | BLE proximity + L2CAP/AACP stem press |
| 2 | samsung_galaxy_buds |
Galaxy Buds 2/2 Pro/3 Pro/Live/FE/Pro | RFCOMM protocol + battery decode |
| 3 | sony_headphones |
WF-1000XM4/5, WH-1000XM4/5, LinkBuds | RFCOMM serial + capability detection |
| 4 | nothing_ear |
Nothing Ear 1/2/a, CMF Buds | RFCOMM serial |
| 5 | oppo_realme |
Oppo Enco, Realme Buds, OnePlus Buds | RFCOMM serial |
| 6 | librepods_airpods |
AirPods (legacy) | BLE proximity + AACP |
| 7 | android_media_session |
ALL Bluetooth audio | Media3 session universal fallback |
| 8 | assistant_entry |
ALL devices | Long-press assistant fallback |
| 9 | generic_bluetooth_headset |
ALL Bluetooth headsets | Connection + audio route awareness |
| 10 | generic_gatt_battery |
BLE devices with BAS | Standard GATT battery service |
Each provider implements a common EarbudSignalProvider contract: identity, capability profile, device state, events, probe, start/stop. The SignalProviderRegistry manages priority, health tracking, and dynamic preferred-provider selection. Vendor-specific code is isolated in per-family packages under signal/vendor/. Shared transports (BtClassicSerialTransport, L2capAapTransport) are reused across providers.
# TypeScript bridge
npm run typecheck # tsc --noEmit
npm run build # tsc -p tsconfig.json
npm test # vitest run (123 tests)
npm audit # see SECURITY.md for advisory notes
# Android relay
cd android-relay
./gradlew :app:assembleDebug
./gradlew :app:assembleRelease
./gradlew :app:lintDebug
./gradlew :app:testDebugUnitTest| Area | Delivered state |
|---|---|
| Safety model | Deny-by-default intents, approval-required actions, hard-approval actions, explicit workspace config |
| Developer actions | Quick status, diff summary, CI failure lookup, run tests, open file, commit message, commit staged, push, deploy, delete, revert |
| Background work | Queueing by workspace, deferred notifications, queued cancellation, truthful running-task cancellation responses |
| OpenClaw | Rewrite-only integration boundary with http, local-cli, and gateway-client transports |
| Android | 10-provider earbud mesh with priority fallback, health tracking, and setup proof |
| Android install | Validated emulator flow + real-device install on realme RMX3990 (Android 16) |
| Observability | Health endpoint, audit log, rewrite metadata, action ids, and relay service logs |
Simulator / Android Relay / Future Earbud Transport
-> Bridge Runtime
-> Event Router
-> Policy + Session Store + Audit Log
-> Local Jarvis Runtime
-> Optional OpenClaw Rewrite Layer
-> Console / JSON / Android TTS Response
| Layer | Responsibility |
|---|---|
| Event source | Simulated earbuds today, Android relay today, real firmware/BLE later |
| Bridge | Validation, session state, health, audit logging, routing |
| Policy | Allowlists, approval classes, workspace boundaries, redaction |
| Jarvis runtime | Intent resolution and actual local dev-tool actions |
| OpenClaw | Response rewriting only, never policy or execution authority |
| Android relay | Capture wake flows, send events, play spoken responses |
npm installnpm run devpods -- start --port 4545For Android relay onboarding on a trusted LAN, prefer a LAN-reachable host or set an explicit pairing base URL:
npm run devpods -- start --host 0.0.0.0 --relay-token relay-secret --pairing-base-url http://192.168.1.10:4545When pairing is available, the bridge now prints both a browser-usable pairing page and the underlying devpods://pair link. Open the printed pairing page on the phone, then tap the pairing button to launch DevPods Relay.
The pairing page also works as a desktop onboarding surface now: it renders a QR code for the pairing page URL so the Android relay can scan the bridge directly from the desktop screen.
Or run the compiled CLI directly:
npm run build
node dist/src/cli/jarvis-earbuds.js start --port 4545Quick status:
npm run send:event -- left_long_pressVoice command:
npm run say -- "summarize my current diff"Local one-shot execution without the HTTP server:
npm run cli -- local left_long_press| Mode | Purpose |
|---|---|
local |
Built-in Jarvis runtime only |
openclaw + http |
Fast deterministic integration and mock validation |
openclaw + local-cli |
Simplest real full OpenClaw execution baseline |
openclaw + gateway-client |
Resident OpenClaw connection for real gateway contract validation |
Examples:
npm run cli -- start --brain openclaw --openclaw-transport http --openclaw-base-url http://127.0.0.1:8080 --openclaw-token dev-tokennpm run cli -- start --brain openclaw --openclaw-transport local-cli --openclaw-model openai/mock-rewrite-model --openclaw-config-path ./runtime-data/openclaw.json --openclaw-state-dir ./runtime-data/openclaw-state --openclaw-workspace-dir .npm run cli -- start --brain openclaw --openclaw-transport gateway-client --openclaw-base-url http://127.0.0.1:8080 --openclaw-model openai/mock-rewrite-model --openclaw-agent-id jarvis_rewrite --openclaw-token dev-tokenThe shipped default is adaptive rewriting with a 250 ms foreground budget and a 750 ms background budget so slow rewrites fall back to the local reply instead of blocking ear-level interactions.
The repository includes a working Android software relay prototype under android-relay/README.md.
What is validated today:
- debug and release builds from the checked-in Gradle wrapper
- installed debug APK on the Android emulator
- relay start and explicit health check
- quick status shortcut
- synthetic headset wake event path
- product-state UI for
Ready,Listening,Thinking,Speaking,Approval required, andAttention needed - hardware-verification UI showing whether the last wake came from a physical media button, push-to-talk, or debug injection
- approval prompt for
open file docs/vision.md - cancel, second prompt, approve, and stop
- explicit
pendingActionIdforwarding and stale-state cleanup checks - bounded autonomy loop for safe background work: spoken completion report, silence-driven continuation, and interrupt-to-replan
- first-pass pairing flow through
GET /pairing, printed bridge pairing page URLs, and stageddevpods://pairimport on Android - QR pairing flow through the bridge pairing page and the Android relay Pairing card
- real-device field notes for RMX3990 + realme Buds Air7 in docs/10-rmx3990-buds-air7-field-notes.md
For a lightweight desktop package without introducing a new desktop framework, build the portable bridge bundle:
npm run package:bridge:windowsThat creates artifacts/windows-bridge/DevPodsBridgePortable with the compiled bridge, a Windows launcher, a default bridge config, and the pairing page flow. Launch start-devpods-bridge.cmd, then scan the QR from the Android relay Pairing card.
Run the Android relay smoke harness against the bridge:
npm run relay:smokeRun the installed-app emulator validation harness:
.\simulation\android-relay\validate-installed-app.ps1Debug builds allow the automation hooks used by that harness. Treat those hooks as test-only surfaces on emulator or private developer devices.
For laptop-side signal evidence on Windows, the repo now includes:
.\simulation\windows-relay\verify-media-buttons.ps1 -DurationSeconds 30Manual verification on the connected laptop has already observed a real MEDIA_PLAY_PAUSE event from the paired earbuds. That proves the earbuds can emit at least one standard Windows media-key signal, but it does not replace the remaining Android hardware validation path.
Current real-device status on Android is more specific than that: physical earbud delivery is now partially recognized on the RMX3990 stack, but still not reliable enough to call the tap workflow solved. The relay now preserves a bounded autonomy plan across spoken reports, can continue safe next steps on silence, and uses either a wake gesture or assistant long press to interrupt active implementation and capture a revised spoken plan.
DevPods is intentionally conservative.
- Every workspace action is allowlisted in
config/workspaces.json - Approval-required and hard-approval actions are explicit
- The bridge does not expose arbitrary shell execution from spoken text
- Destructive file operations are workspace-bounded
- OpenClaw is a rewrite layer, not the source of truth for permissions or execution
- Audit records and redaction are part of the normal runtime path
The final repo-wide verification reran successfully with:
npm run typecheck
npm test
npm run buildAndroid verification also passed with:
cd android-relay
.\gradlew.bat assembleDebug
.\gradlew.bat assembleRelease
cd ..
.\simulation\android-relay\validate-installed-app.ps1The current automated test suite covers 19 test files and 123 tests.
| Path | Purpose |
|---|---|
src/protocol |
Shared schemas and intent types |
src/policy |
Allowlist, approvals, redaction, workspace boundaries |
src/bridge |
HTTP bridge, runtime, event router, session store, audit log |
src/jarvis |
Intent routing, local runtime, background scheduling |
src/openclaw |
OpenClaw transports, sandboxing, validation, health reporting |
simulation/fake-earbud-events |
Local event fixtures and CLI helpers |
simulation/android-relay |
Android relay validation scripts and smoke harness |
android-relay |
Android software relay MVP |
docs |
Architecture, security, operations, implementation, and Android phase docs |
protocol |
Human-readable protocol references |
LibrePods was used as a local architecture and protocol reference during discovery. The shipped DevPods code in this repository remains a clean-room implementation. The local librepods/ clone is treated as a reference workspace and is excluded from the repo content prepared for publication.
- android-relay/README.md: DevPods Relay setup, UI model, and validation entry points
- docs/09-android-software-relay-mvp.md: Android relay architecture, current evidence, and manual hardware-verification path
- docs/android_relay_vision.md: Android-first product framing
- docs/06-openclaw-runtime-operations.md: runtime flags, env vars, and OpenClaw transport modes
- docs/07-implementation-summary.md: detailed implementation state and engineering summary
- docs/08-acceptance-criteria-status.md: acceptance-criteria tracking
- docs/vision.md: original product framing and firmware-first architecture direction
The next highest-value work is not more simulator polish. It is moving the validated software loop onto real hardware surfaces:
- Add a real BLE or firmware-backed transport adapter behind the existing event contract.
- Validate the Android relay on real headset hardware across multiple device classes.
- Add production-grade STT and TTS paths.
- Continue improving the low-latency full-fidelity OpenClaw path when budgets are disabled.
- Preserve the current safety model while widening transport and hardware support.
DevPods already proves the critical systems problem: safe event intake, workspace-bounded action routing, approval gating, concise spoken response shaping, and optional OpenClaw integration. That is the foundation the hardware layer can now build on.