Turning IP Geolocation on changed nothing: every lookup failed, and the
tool output still said "no Location is set in preferences", which is a
different problem and sent the user looking in the wrong place.
ipapi.co no longer serves an unauthenticated caller. Verified directly:
no User-Agent -> HTTP 429 {"reason":"RateLimited",
"message":"Please sign up for a paid plan"}
browser UA -> HTTP 403, a Cloudflare "Just a moment..." challenge
So the provider is now ipwho.is, which answers 200 without a key. It
signals refusal with success: false on an HTTP 200, so the body is checked
as well as the status, and it nests the timezone under an object, which the
parser now accepts alongside a bare string. A named User-Agent is sent:
node's default is bare, and "who is asking" is the one thing a geolocation
provider has a fair interest in.
The failure branch is also fixed. A failed lookup and an unset preference
are different problems, and the wording no longer conflates them. The note
tells the model to pass the failure on, because the model is the only
channel that reaches the user and it had been paraphrasing the failure away.
Accuracy is documented honestly rather than as "city-level". An IP locates
the ISP's egress, not the person: measured from one machine, an IPv4 query
resolved to Cebu City and an IPv6 query moments later to Talisay in
Calabarzon, about 500km apart. That is now in the README, the preference
description and the tool output, and it is the argument for setting
Location instead.
Verified live with the exact request and field access the extension uses:
HTTP 200, "Talisay, Calabarzon (Region IV-A), Philippines", Asia/Manila.
344 tests, tsc, eslint, prettier, and vici build.
Adds the one thing the extension could not answer before: roughly where
the user actually is, rather than which zone their clock is set to.
- `lib/geo.ts` resolves a place from ipapi.co. Chosen because it is HTTPS
and needs no API key; ip-api.com, the other obvious free option, is
HTTP-only on its free tier, which is not a place to send an IP address.
- Off by default, and skipped entirely when the user has set Location: the
better answer is already there, so spending their privacy on a worse one
would be indefensible. `ipPlace` is only wired into ToolContext when the
preference is on, so an off setting cannot reach the network at all.
- Cached for 6 hours. A city does not change between questions, and every
lookup hands the provider another copy of the address. Set Up Lam Agent
clears it on re-test, alongside the vision cache.
- Failures are returned, not swallowed: a rate limit or an offline machine
says so in the tool output while the region answer stays available. The
provider signals some failures with error: true and HTTP 200, so the body
is checked as well as the status.
- The tool output always names the provider and calls the result city-level
rather than exact. It also flags an IP timezone that disagrees with the
device clock, which usually means a VPN.
- The README claimed no geolocation service ever saw the user's address.
That is now conditional, so the section was rewritten rather than left to
quietly become untrue.
Deliberately not done: GPS. CoreLocation has no CLI on macOS and GeoClue's
usual provider resolves nearby Wi-Fi through a Mozilla service anyway.
Verified: 341 tests (25 new), tsc, eslint, prettier, and vici build. I did
not make a live API call, because doing so would send this machine's IP to
the provider as the exact flow being opted into.
Two changes: screenshot input gated on the model really reporting vision,
and a fix for URLs that arrived as code.
Links
- A fence whose body is all URLs, a lone `https://...` inline span, and a
line that is only a URL are rewritten into [url](url) markdown links.
Vicinae attaches only the table and strikethrough GFM extensions, so
autolink is off and a bare URL is dead text; clickability comes from
MarkdownModel turning CMARK_NODE_LINK into an <a href>. A fenced URL was
a dark panel with a Copy button and no way to open it.
- promoteStandaloneCodeSpans was itself promoting a lone URL span into a
fence, so it made this worse. Link restoration now runs first.
- The default prompt says never to fence a URL.
- Anything that is not one of those three shapes is copied through, so a
curl invocation containing an address is never rewritten.
Screenshots
- capture.ts shells out to an auto-detected tool: grimblast, grim + slurp,
spectacle, maim, scrot, flameshot, or screencapture on macOS. There is
no screenshot call in @vicinae/api and Clipboard moves no binary, so the
extension owns the capture and reads the file it wrote rather than
guessing at the clipboard. Cancel is detected by whether an image landed
on disk, because the tools disagree on exit codes.
- In chat: "Snip a Region" in the action panel (cmd+shift+S) attaches to
the current conversation. Standalone: "Snip to Lam" starts a new one.
- vision.ts caches the /api/show capability answer per host and model. A
failed check is "unknown", never "no", so a dropped connection is not
reported as a fact about the user's model. Actions still fail closed.
- Only the path is stored, base64 is read at send time, and the image goes
on its own turn only. Capture is never a model-callable tool.
Verified: 244 tests, tsc, eslint, and vici build (both entrypoints).
adrianbonpin