Skip to content

Environment Context

When you ask an AI “what time is the next flight?”, it needs to know your timezone. When you ask “find me a good restaurant nearby”, it needs to know where you are. By default, most AI models have no idea about either. Daneel’s environment context system solves this by injecting location, datetime, and timezone data into the system prompt before the AI sees your message.

When enabled, Daneel adds an ## Environment Context section to the system prompt:

## Environment Context
- Location: Lyon, France
- Current date/time: 2026-04-02T14:30:00.000Z
- Timezone: Europe/Paris

The AI reads this as part of its instructions and can reference it naturally in responses. There is no special API or tool involved — the context is plain text, visible to the model alongside the rest of the prompt.

Context injection uses a layered permission model. All three tiers must agree before data is injected.

Two toggles in Settings > Privacy control what the extension is allowed to share:

  • Share location with agents (off by default) — controls geolocation
  • Share date & timezone with agents (on by default) — controls datetime/timezone

If a toggle is off, that data type is never injected, regardless of what agents or MCP servers request. This is the hard override.

Each registered MCP server can declare whether its tools benefit from context:

  • requiresLocation — tools like Google Maps, weather APIs, or local search
  • requiresDatetime — tools that deal with scheduling, deadlines, or time-sensitive data

These flags are toggled per-server in Settings > MCP via clickable location and datetime badges on each server row.

Each agent has optional override fields:

  • Uses location — force on/off regardless of bound servers
  • Uses date & time — force on/off regardless of bound servers

When unset (the default), the agent inherits from its bound MCP servers: if any bound server declares requiresLocation, the agent gets location injected.

Agent explicit flag (if set)
→ else: inherit from any bound MCP server
→ else: defaults (location=false, datetime=true)
→ gated by global privacy toggles

Datetime defaults to true because it has zero privacy cost (it uses Date and Intl.DateTimeFormat — no network calls, no permissions). Location defaults to false because it requires browser geolocation permission.

The geolocation pipeline has several steps, each designed to degrade gracefully:

  1. The background service worker sends a geo-request to the host page (an extension page with DOM access)
  2. The host page calls navigator.geolocation.getCurrentPosition() with enableHighAccuracy: false (WiFi/IP-level, not GPS)
  3. If the user grants permission, the host returns latitude and longitude
  4. The background calls Nominatim (OpenStreetMap’s free reverse geocoder) to convert coordinates into a city name
  5. The result (e.g., “Lyon, France”) is cached in memory for the session

If any step fails — permission denied, timeout, geocoding error — the location is silently omitted. No error is shown to the user; the prompt simply proceeds without location context.

navigator.geolocation is not available in Chrome extension service workers. Calling it from a content script would prompt the user against the host site’s origin (“example.com wants your location”), which is confusing. By using the extension’s own host page, the permission prompt correctly shows the extension name.

When you toggle “Share location with agents” on for the first time:

  1. The host tab is briefly focused so Chrome can show its native geolocation prompt
  2. You grant or deny the permission
  3. Focus returns to your original tab automatically
  4. If you denied, the toggle stays off

This only happens once. After granting permission, location resolves silently on subsequent uses.

  • The resolved location is cached in memory for the browser session (cleared when the service worker restarts)
  • The browser’s own position cache (maximumAge: 300,000ms) avoids repeated GPS/WiFi lookups
  • Nominatim is called at most once per session — well within its 1 request/second policy
  • No location data is written to chrome.storage or persisted to disk

Datetime injection is trivial by comparison:

  • new Date().toISOString() for the current timestamp
  • Intl.DateTimeFormat().resolvedOptions().timeZone for the IANA timezone (e.g., Europe/Paris)

No permissions, no network calls, no caching needed. The value is computed fresh on each message.

Environment context follows Daneel’s privacy model:

  • Geolocation stays between your browser and Nominatim (for reverse geocoding). The resolved city name is only sent to your selected LLM provider as part of the prompt. Nominatim receives coordinates but no user identity — requests use a generic DaneelAI-Extension user-agent.
  • Datetime never leaves your browser until it’s embedded in a prompt sent to the LLM.
  • Neither type is stored in chrome.storage, included in data exports, or sent to telemetry. The in-memory cache is lost when the service worker restarts.

The telemetry system has its own separate IP-based geolocation (for country/region analytics), which is independent and governed by the “IP geolocation” toggle. The two systems do not share data.

ScenarioLocationDatetime
Agent with usesLocation: trueYes (if global gate on)Yes
Agent inheriting from MCP server with requiresLocationYes (if global gate on)Yes
Bare MCP server usage (no agent)Inherits from server flagsYes
Page Q&A or Site RAG (no agent, no MCP)NoYes

Datetime is injected in all scenarios by default, including plain page questions. This gives the AI temporal awareness even without agents or tools — useful for questions like “is this documentation still current?”