The Aldi skill started with a very practical goal: turn the weekly grocery reorder into a Slack conversation instead of another browser chore.

The obvious version sounds simple. Open Aldi, look at the last order, rebuild the cart, ask what should change, pick a pickup slot, and stop before payment. The real work was not the shopping list. The real work was authentication.

The auth problem

Aldi's site supports Google sign-in, which is convenient for a human and annoying for automation. A normal bot browser or Selenium-style flow is exactly the kind of thing Google does not trust. That is good security. It is also a hard stop if the plan depends on replaying a login flow.

The fix was to stop pretending the bot should log in like a bot.

We used a real Chrome install on the VM, a persistent Chrome profile, and a one-time human login through noVNC. The VM runs the browser behind a small desktop stack: Xvfb for the display, fluxbox for the window manager, x11vnc and websockify for browser access, and Chrome with a remote debugging port enabled.

From a Mac, the flow is straightforward:

  1. Open an SSH tunnel to the VM.
  2. Connect to the noVNC browser view.
  3. Complete the Google sign-in manually in real Chrome.
  4. Keep the same Chrome profile so the trust state and cookies persist.
  5. Have OpenClaw attach to that live session over Chrome DevTools Protocol.

The important design choice: do not automate the Google login. Automate after the trusted browser session exists.

Verification beats hope

We also did not count "the tab is open" as proof that the bot was authenticated. The automation verifies the live browser over CDP and checks for page signals that actually matter: sign-in is absent, the Buy It Again section is present, the account context is visible, and the selected store and cart context are available.

That gave us a reusable pattern: human handles the sensitive login once, the VM preserves the browser profile, and automation only proceeds when the live storefront proves it is signed in.

What the Aldi skill does now

The current skill is intentionally narrow. It manages a reorder draft and keeps the human in control.

  • Fetches the latest order: reads the recent Aldi order summary and extracts item names from the live signed-in session.
  • Builds a draft: creates a reorder draft with the prior items as the starting point.
  • Posts to Slack: sends the draft into a Slack DM thread with the store context, pickup estimate, and initial slot options.
  • Supports simple edits: replies like exclude milk, include bananas, and show update or display the draft.
  • Refreshes pickup slots: show slots pulls current pickup options from the live checkout flow.
  • Selects a slot: slot 2 chooses one of the numbered pickup windows and stores it on the draft.
  • Adds new items: add eggs searches Aldi, auto-adds a clear match, or returns candidates when the search is ambiguous.
  • Runs continuously: a user systemd service polls the Slack thread and applies commands without needing a manual shell session.

The command model

The interface is deliberately boring. That is a compliment. The useful commands are short, predictable, and easy to type from a phone:

  • exclude <item words>
  • include <item words>
  • add <item words>
  • show
  • show slots
  • slot <n>
  • confirm
  • cancel

Matching is substring-based and case-insensitive. If I say exclude yogurt, it can remove every draft item matching yogurt. That is not fancy natural language processing. It is the smallest thing that works and is easy to audit.

The safety boundary

This version does not place the order. It does not submit payment. That is intentional.

The skill can assemble the draft, update the item list, search for additions, show live pickup slots, and select a pickup window. The final purchase boundary stays human-controlled. Grocery automation is useful. A bot accidentally buying twelve bags of cauliflower rice because I typed a lazy command is less useful.

Why this matters beyond groceries

The Aldi skill is a small personal workflow, but the architecture is bigger than groceries:

  • Use a real browser profile when modern auth flows require real user trust.
  • Separate authentication bootstrapping from day-to-day automation.
  • Verify state through the live app, not assumptions.
  • Expose the workflow where the human already works, in this case Slack.
  • Keep risky actions behind an explicit human boundary.

That pattern applies to a lot of personal and enterprise automation. The win is not "AI buys groceries." The win is turning a recurring, low-value workflow into a controlled assistant loop with clear state, clear commands, and a safe stop before irreversible action.

Next up: tighten the Sunday reminder flow, improve item matching, and decide whether order submission should ever be automated. My current answer is "probably, but only with a very boring confirmation step." Boring is underrated when money leaves the account.

OpenClaw Browser Automation Google Auth Slack Personal Automation