████      ████
██    ██  ██    ██
  ██████████████     Robomart Command
      ██  ██         Delivery on command
  ██████████████     /help for commands
██    ██  ██    ██
  ████      ████

Robomart Command is an end-to-end agentic commerce and delivery harness: the command line for the physical world. Run deterministic commands directly, or run bare robomart to work with an agent from shopping and ordering through payment, preparation, and delivery. Execution depends on the merchant, payment, and delivery tools connected to the session. Agentic mode uses Claude, ChatGPT, Grok, OpenAI, Fireworks, or OpenRouter credentials.

Get anything from existing retailers with online ordering and curbside pickup, subject to availability and robot route/parcel limits. Command uses the retailer's existing checkout and curbside process. When RM5 arrives, alert the store with the order and bay/location; staff bring out the prepaid goods, scan the vehicle QR, identify the order, and load the assigned locker. No separate merchant onboarding or advance loading agreement is required by this workflow. See agent product guidance before changing these assumptions.

• $2.99 flat per eligible Robomart robot delivery, up to 5 routed miles inside one live zone and within the locker envelope. One call at the posted price, booked or refused.
• The Delivery MCP (mcp.robomart.ai) provides coverage, robot booking, tracking, cancellation, and proof. Merchant discovery, checkout, and goods payment require their own connected capabilities.
• Goods must be purchased, packed, and ready when the robot leg is booked. Command 1.2 includes the commerce runtime; check src/commerce/ and the commerce acceptance ledger before claiming a particular retailer checkout is qualified. Source implementation, package availability, and retailer acceptance are separate facts.
• In ask permission mode, review the MCP tool name and arguments and approve the request before it runs. This applies to booking and read-only Delivery MCP calls.

Install

npm i -g @robomart/command                     # macOS (Apple silicon and Intel)
brew tap robomart-ai/tap && brew install robomart
# source development: npm run build:dev (see below)
robomart                                       # opens agentic mode
robomart --help                                # lists deterministic commands

Sign in

• robomart login robomart — sign in to Robomart: paste an rm_sk_* key from Console, or add --device to approve the sign-in in Console. The key is saved under ~/.command/ and the Delivery MCP is connected.
• robomart login claude|codex|grok — bring the AI subscription you already pay for.
• /login — switch provider or paste a provider API key.
• /model — pick the model and reasoning effort.

In the source preview, ask Command to connect Robomart when robot pickup is needed. It can present a Console approval link and resume sign-in in the same conversation; credentials stay outside chat. This device flow requires the updated authorization service and refuses the older code-only redemption flow. The shell command robomart login robomart remains available for privately pasting a Delivery key. Commerce and /wallet can read the saved key immediately; /mcp reload refreshes the direct Delivery MCP connection without restarting the conversation. /login inside agentic mode selects an AI provider.

Discovery does not require Robomart login. Connect the merchant account when that store requires it, and connect Link before requesting goods-purchase approval. If the purchase depends on robot pickup, connect Robomart and check the route and delivery balance before buying. Provider login, merchant login, Link approval, Delivery access and Wallet management are separate authorities.

Saved customer details

Ask Command to connect my personal profile. Open its Console approval link, sign in with your personal passkey and approve the matching code. Command saves a separate, revocable profile credential privately; an organization Delivery key cannot access personal details.

Name, phone, contact email, preferences and named addresses such as office and home live in Console's account database. Command refreshes them before each user turn, including a new conversation or restarted process. Explicit personal facts and corrections are saved through commerce_profile_update; one-off recipients and product choices do not replace defaults. Ask to show, update or forget details, or disconnect your profile. Connected devices can also be revoked at Console.

The private cache under ~/.command/commerce/ supports recall during a temporary outage and is marked stale. It expires after one day, cannot save offline changes, and is removed on sign-out or rejected credentials. Device access expires after 90 days; account recovery revokes it immediately. Profile connection does not approve purchases or deliveries.

Link status distinguishes sign-in from its payment scope. When the current session explicitly lacks payment access, Command requests the missing scope through Link's browser approval while keeping the old session valid. This connection approval never approves a goods purchase.

Pending purchases retain their Link approval URL across interruptions. Complete card or identity verification in Link's browser flow, then resume the purchase in Command. A resumable card challenge keeps the same payment request; an uncertain merchant submission still requires reconciliation before any retry.

Commerce and discovery

Command 1.2 bundles the commerce connector. Node 22 or newer must be on PATH. Link purchases require @stripe/link-cli; browser checkout requires agent-browser. The optional Domino's and Instacart PP tools are detected when installed.

Kernel is the default browser provider. Configure KERNEL_API_KEY, or save an api_key string in ~/.command/kernel.json with owner-only permissions (chmod 600). The environment variable takes precedence. Command uses a persistent cloud profile for each merchant; routine shopping does not open local Chrome. A required login or verification can open the same hosted browser's live view for the customer. Local Chrome remains an explicit provider: "local" choice and requires Chrome to be installed. Kernel failure never silently switches to local Chrome.

Command searches Google Places and Maps for the requested goods near the supplied destination, then follows direct merchant websites. Local web search broadens local pickup discovery; shipping and marketplaces require an explicit fallback choice. Search keys stay on Robomart’s service and discovery needs no Delivery login. Public merchant inspection reads UCP profiles and structured product claims; shipping-only connectors are excluded from local pickup. None of these observations proves branch stock, quantities or selected curbside fulfillment.

The runtime supports merchant discovery, exact cart review, Link approval, one purchase submission, receipt reconciliation, preparation observation, pickup confirmation and the robot leg. A robot-dependent purchase must verify selected curbside pickup; generic carryout is insufficient. The browser review asks the user to verify curbside when merchant wording is ambiguous. Browser preparation is read from the original receipt page with its exact saved order ID and total; estimates and ambiguous status text never establish readiness. The page can be observed for up to 30 seconds per call without refreshing or resubmitting checkout. Browser-checkout review, delivery approval and the manual readiness fallback require human answers even in YOLO mode. A timeout after purchase submission requires reconciliation before another attempt. Test Link credentials cannot reach a live merchant, and sandbox robot access cannot authorize goods purchases that depend on real robot pickup.

Browser inspection supplies CSS selectors and field metadata without input values, including while payment details are present. Receipt selectors can be discovered after submission and attached during verified reconciliation. Observed receipt or order-status links can open a new page in the same browser without exposing their private addresses. The saved order ID and approved total must still match; navigation never authorizes another purchase.

Command follows retailer links to their ordering providers in the same browser, inspects guest checkout and dismisses optional sign-in prompts. A different domain does not imply a login challenge. Recoverable page failures allow inspection and public navigation; the agent handles recovery. An actual blocking authentication or verification step is identified separately from an explicit customer handoff. Passwords and one-time codes are not chat inputs, and interactive snapshots omit field values. Failed navigation preserves the browser and any saved purchase; checkout origin and submission protections remain pinned after review. Access failures do not establish product availability, and incident/network details stay private. Loading pages allow up to 15 seconds for content to appear before recovery. Payment fields and purchase controls still require checkout review. Product and store search inputs support Enter without exposing a purchase shortcut.

commerce_curbside_checkin supports arrival forms in the original merchant browser that accept a message or vehicle/location text fields and show an acknowledgement. It requires authenticated tracking for the exact order with a recent arrived_pickup_at, an assigned vehicle and live service. It uses the reported pickup location; it never invents a parking bay. Repeated calls reconcile uncertain submissions without notifying again. Other forms and merchant challenges use the existing browser handoff. Check-in does not prove loading or custody.

The expanded local Chrome checkout, preparation and check-in fixture passed. Live merchant purchases and pending Stripe capabilities remain unqualified. Instacart's PP connector has catalog/cart operations and no checkout; its sign-in is separate from Command's dedicated browser profile. Domino's direct adapter currently selects Carryout, so robot-dependent purchases need a browser-verified curbside selection. Merchant-specific preparation/check-in acceptance and physical robot fulfillment must be qualified separately from the packaged runtime. See the commerce plan and acceptance record for the exact boundaries.

The robot delivery leg

One call, posted price, booked-or-refused:

robomart> Order #4412 is ready for pickup at Best Buy on Park Ln — get it to my door within the hour

The agent can check robot coverage and the posted $2.99 price, book the delivery, and track its status. In ask permission mode, each MCP request pauses for approval. Outside a live robot zone, the request is refused with on_network_unavailable.

Surfaces

• robomart wallet — live balance and environment
• robomart spend — spend this month against the Wallet cap
• robomart coverage "<pickup>" "->" "<dropoff>" — robot-zone eligibility, posted price, arrival window
• robomart deliveries — the newest page of the org's deliveries
• robomart doctor — what's connected, what's missing

For developers

Robomart Command is built on an Apache-2.0 terminal-agent chassis; third-party attribution is in THIRD_PARTY_NOTICES.md. Use Zig 0.16.0. On Apple Silicon use the aarch64 macOS compiler, even when the terminal runs under Rosetta. COMMAND_ZIG can point to its executable. The build wrapper also checks ~/.local/share/command-toolchains/zig-aarch64-macos-0.16.0/zig and /opt/homebrew/bin/zig. Download the matching compiler from ziglang.org.

For local changes, build one native Debug executable:

npm run build:dev
./zig-out/dev/bin/robomart
npm run test:unit -- -Dtest-filter=ui.auth_gate_screen

-Dtest-filter accepts a test-name substring and can be repeated. test-unit excludes the benchmark suites; plain zig build test includes them and thousands of application tests. Run only the tests relevant to the change. To exercise the development binary in isolated terminal sessions:

COMMAND_TEST_BINARY=zig-out/dev/bin/robomart COMMAND_TEST_ISOLATED_TMUX=1 \
  bun test tests/e2e/tui-auth-source-selection.test.ts \
  --test-name-pattern 'Fireworks environment logout' --max-concurrency 1

Build the universal optimized package only after the source and welcome animation are settled:

npm run build:release
node scripts/check-npm-package.mjs

Release packaging requires Apple Silicon with Rosetta so both shipped architectures can be executed. It builds each architecture once into separate output directories and replaces bin/command only after both report the package version. Publishing remains a separate operation.

The native ARM compiler produces both release architectures; an Intel compiler is unnecessary. Intel compatibility adds a release build, not a second development build. Use the npm scripts so a translated terminal cannot accidentally select an Intel compiler from PATH.

License

Apache-2.0. See LICENSE and THIRD_PARTY_NOTICES.md for third-party attribution.