Supermarket
WarnAudited by ClawScan on May 10, 2026.
Overview
The skill matches its grocery-shopping purpose, but cart/profile use routes reusable Kroger OAuth tokens through a hosted proxy with loose scope and retention boundaries.
Product and store searches are lower risk, but do not use cart or profile features unless you are comfortable logging into Kroger through the hosted proxy. Check the OAuth permissions, keep the login link private, confirm every cart change, and consider self-hosting or revoking access after use.
Findings (7)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Anyone with access to the cached token or agent context could potentially read Kroger profile data or add items to the user's cart until the token expires or is revoked.
The skill directs the agent to receive and cache reusable Kroger OAuth tokens for profile and cart operations, but the artifacts do not specify a secure cache location, retention limit, or revocation workflow.
If HTTP 200: tokens are returned. Cache `access_token` and `refresh_token`.
Treat this as a credentialed account integration: use it only in a trusted agent environment, revoke access after use, and prefer a version that stores tokens in a secure vault with clear expiry and deletion behavior.
A manipulated login URL could ask the user to approve broader Kroger permissions than the skill's normal cart/profile scope, if the Kroger app is allowed to request them.
The OAuth scope can be supplied through the request query rather than being fixed or allowlisted in the proxy.
const scope = (req.query.scope as string) || "cart.basic:write profile.compact";
The proxy should ignore arbitrary scope input or validate it against a narrow allowlist, and users should check the permissions shown on the Kroger login/consent page.
A failed or abandoned login completion flow could leave reusable account tokens stored on the hosted proxy longer than the user expects.
The hosted callback stores access and refresh tokens in Firestore. The provided tokenUser code deletes after successful retrieval, but the artifacts do not show automatic cleanup for completed sessions that are never polled.
await sessionRef.update({ access_token: data.access_token, refresh_token: data.refresh_token, expires_in: data.expires_in, token_type: data.token_type, completed: true });Add enforced Firestore TTL/scheduled cleanup, avoid storing refresh tokens when possible, and document exactly where tokens are stored and when they are deleted.
Users may trust the hosted proxy more than the provided code fully supports, especially for refresh-token retention.
This assurance is stronger than the visible implementation: tokens are stored after a successful callback and deletion is tied to later tokenUser retrieval, with no artifact showing cleanup for unclaimed completed sessions.
Privacy guarantees (verifiable in source): ... User tokens are **deleted from Firestore immediately** after being returned to the agent ... Login sessions **expire after 5 minutes**
Align the privacy wording with the implementation, or add enforceable cleanup and include the relevant rules/TTL configuration in the reviewed artifacts.
The agent could add the wrong item or quantity if the user's request is ambiguous.
The skill/CLI can mutate the user's Kroger cart. This is purpose-aligned, but it is still an account-changing action.
err = client.AddToCart([]krogerapi.CartItem{{UPC: c.UPC, Quantity: c.Qty}})Confirm the product, store context, and quantity before adding items to the cart.
If used, the login session link is exposed to Telegram and whoever can access that chat or bot configuration.
An optional CLI path can send the OAuth login URL through Telegram using a bot token/chat ID.
msg := fmt.Sprintf("Kroger login URL:\n%s", loginURL) ... telegram.SendMessage(cfg.BotToken, cfg.ChatID, msg)Avoid the Telegram option for sensitive accounts unless the bot and chat are trusted, and keep the login link private.
Users have less registry-level provenance for the deployed proxy that receives their OAuth flow.
The registry metadata does not bind the skill to an official source or homepage, which matters because the workflow depends on a hosted OAuth proxy handling user tokens.
Source: unknown; Homepage: none
Verify the linked repository and hosted proxy ownership before logging in, or self-host the proxy if available.