---
title: Support
description: How to get help with Extentos — self-service diagnostics through the extentos-mcp CLI (whoami, status, getEventLog), what to include when you email support so it's actionable across the four components (MCP server, native libraries, backend, simulator UI), the security disclosure path, and pre-1.0 response expectations. No paid support tiers exist at launch.
type: resource
platform: all
related:
  - /docs/resources/faq
  - /docs/resources/security
  - /docs/resources/changelog
  - /docs/mcp-server/auth
---

Extentos is pre-1.0 — support today is direct (email) plus a deep self-service surface. There's no paid support tier and no SLA. What there is: a structured-event-log debugging surface that makes most issues self-diagnosable from your own machine, and a maintainer who reads every message. This page is where to start when something goes wrong.

## Where to send it

The quickest route is the **[contact form](/contact)** — pick a topic and it lands in the same inbox, already tagged, with your reply address attached.

If you'd rather use your own mail client, email **[hello@extentos.com](mailto:hello@extentos.com)** with a subject prefix so it routes fast:

| Issue type | Subject prefix |
|---|---|
| Bug reports (something is broken) | `[bug]` — include the bug-report checklist below |
| Feature requests | `[feature request]` |
| Documentation gaps or errors | `[docs]` — include the page URL |
| Vendor support requests (any smart-glasses maker) | `[vendor]` — include the public SDK link |
| Security issues | **Use the private path** — see [security disclosure](#security-disclosure) below |
| General questions | `[question]` — also see [FAQ](/docs/resources/faq) for common answers |

A public issue tracker and Discussions may open as the project approaches 1.0; for now email is the canonical channel.

## Self-service before filing

Most issues are diagnosable from the developer's machine without escalation. Before opening an issue, run through this:

### 1. Capture install state with `whoami`

```bash
npx @extentos/mcp-server@latest whoami
```

Prints the install ID, account ID (if linked), tier, meter remaining, auth expiry, and MCP / library versions. **Always include this output in a bug report** — it's the single line that tells maintainers what your install actually looks like.

### 2. Check consent and config state with `status`

```bash
npx @extentos/mcp-server@latest status
```

Prints consent state (privacy notice accepted / declined), telemetry on/off, install ID, linked account, and effective config dir (`~/.extentos/` or whatever `EXTENTOS_CONFIG_DIR` points at). Useful when an issue might be config-related.

### 3. Ask the agent to query the structured event log

If the bug is "something happened at runtime," the structured event log is the primary debugging surface. Tell your AI agent:

```text
Run getEventLog with filter "errors" and limit 50 on session <sessionId>
```

The agent calls the MCP tool; the response is a structured trace of what happened in the simulator session — every capability call (record, capture, speak, …) emits a request + result event with a stable id, and any failure routes to the `errors` chip. Filter by chip (`errors` / `voice` / `camera` / `display` / `ai` / `lifecycle` / `custom`) to narrow to one modality.

### 4. Run `validateIntegration` for integration issues

If the symptom is "agent says everything is fine but the app doesn't run," ask your agent:

```text
Run validateIntegration on this project
```

`validateIntegration` checks the generated connection module against the manifest, the dependency list, handler wiring, required permissions, and bootstrap setup. It catches most class-of-issue mismatches before they become runtime bugs.

### 5. Reproduce against the published packages

If a behavior contradicts what's documented, pin the exact published versions and capture a minimal repro:

- MCP server — [`@extentos/mcp-server`](https://www.npmjs.com/package/@extentos/mcp-server) (npm, MIT)
- Android library — [`com.extentos:glasses`](https://central.sonatype.com/artifact/com.extentos/glasses) (Maven Central)
- iOS library — [`Extentos`](https://github.com/extentos/swift-glasses) (Swift package, swift-glasses on GitHub) — pin the version as shown in the [iOS install guide](/docs/sdk/ios/install)

Reports that include the exact versions (`whoami` output) and a `getEventLog` trace are easiest to triage.

## What to include in a bug report

A useful bug report has six things. Maintainers can act on a bug with this; they often can't without it.

```text
1. Extentos version          — output of `whoami` (mcpVersion + libVersion)
2. Platform                  — Android API level, or iOS version + device model
3. Agent host                — Claude Code / Cursor / Windsurf / Cline / other
4. Steps to reproduce        — exact agent prompts + commands run
5. Expected vs actual        — what should have happened, what did
6. Logs                      — getEventLog output if applicable, otherwise
                                Logcat (Android) / os_log (iOS) / MCP stderr
```

If the bug involves a simulator session, also include:

- `sessionId` (if active or recent)
- The capability call that failed (e.g. `capture_photo`, `record_discrete`, `speak`) and its event id from `getEventLog`
- Whether the simulator browser tab was open
- `autoOpenAttempted` and `autoOpenPlatform` from the `createSimulatorSession` response

If the bug involves real hardware:

- Ray-Ban Meta variant (Gen 1 / Gen 2 / Display)
- Frame style (Wayfarer / Headliner / Skyler / etc.) if relevant
- Bluetooth pairing status before the bug
- Whether the bug repros on `LocalSimTransport` (the in-memory local sim) too

If the bug involves cross-platform behavior, repro on both iOS and Android if you have access — or note which platform you couldn't test.

## Component triage — figuring out which component owns the bug

Extentos has four main components, and one common reason bug reports go cold is mis-routing. Here's the rule of thumb:

| Symptom | Likely component |
|---|---|
| MCP tool call returns an error or hangs | **MCP server** (`mcp-server/src/`) |
| Agent generates wrong / broken code into the app | **MCP server** — code generators in `mcp-server/src/tools/handlers/` |
| Speech recognized but your wake-phrase handler doesn't react | **Your handler code** first (the phrase match runs in your handler over `glasses.audio.transcriptions()`), then the **native library** if the transcription events themselves are wrong |
| Simulator browser tab shows wrong frames or doesn't accept input | **Simulator browser UI** (`src/components/simulator/`) |
| Simulator session expires immediately, fails to provision, or returns 5xx | **Backend** (`backend/src/`) |
| `RealMetaTransport` BLE link drops, photo capture fails on hardware | **Native library** + maybe Meta DAT itself |
| Permission request denied on Android 14, capability silently no-ops | **Native library** — permission derivation in `permissions.ts` and runtime handling |
| `getPermissions` returns the wrong permission set for your handler's capabilities | **MCP server** — `mcp-server/src/tools/util/permissions.ts` |

Most bugs are at the boundary between two components — e.g., the MCP server generates a manifest, the library reads it. Including `getEventLog` output usually disambiguates which side actually misbehaved.

## Security disclosure

**Do not report security issues publicly.** Email **[hello@extentos.com](mailto:hello@extentos.com)** with subject prefix `[SECURITY]`. Include:

- Affected component (MCP server / library / backend / simulator UI)
- Affected version
- Reproduction steps
- Impact assessment (data exposure, privilege escalation, etc.)
- Whether you've shared this with anyone else

Acknowledgment within 7 days. Patch timeline depends on severity:

- **Critical** (RCE, auth bypass, mass data exposure): patch within 14 days, coordinated disclosure thereafter
- **High** (PII exposure, single-user data leak, persistent XSS): patch within 30 days
- **Medium / Low**: patched in the next minor release

The Extentos library architecture is designed to minimize blast radius — `RealMetaTransport` doesn't connect to the Extentos backend, and handler-code input/output payloads (which may contain end-user data) never reach Extentos servers. AI keys for handler-code calls live entirely in your app; for the [managed AI gateway](/docs/concepts/ai-gateway), Extentos relays the call on its own key — there is no bring-your-own-key option — but the conversation content is never stored — only token-usage metadata. Most security-relevant code paths are in the MCP server and the simulator/gateway backend; these are the areas most worth careful review by external researchers.

See [security and data handling](/docs/resources/security) for the full architectural privacy story.

## Response expectations

Pre-1.0 means honest expectations:

- **Bug acknowledgment**: typically 1–3 business days. Sometimes longer when the maintainer is heads-down on the next release.
- **Bug fix timeline**: triaged by severity. Crashes, data corruption, or security issues land in a same-week patch release. Feature gaps, minor inconsistencies, or polish items land in the next minor (`@0.0.x` → `@0.0.x+1`).
- **Feature requests**: read and considered, but no commitment to a timeline. The roadmap is community-shaped — popular requests with clear use cases land sooner.
- **Vendor-add requests** (e.g., "add Brilliant Labs"): tracked but require the vendor's SDK to be public + sufficiently mature, and hardware people can actually buy. See [vendors](/docs/vendors) for current support state.

There is no paid support tier with a faster SLA at launch — this may change post-1.0.

## When the agent itself can debug

A frequently-overlooked debugging path: **ask your AI agent to triage**. Modern AI coding agents reading a structured `getEventLog` response can often pinpoint the failing layer faster than a human scanning the same trace. Try:

```text
My "describe the scene" feature failed. Run getEventLog with filter "errors"
on the active session, read the trace, and tell me where it broke — the
capability call (camera/audio), my handler logic, or the transport.
```

The agent has direct access to the MCP debug surface; it can correlate a capability request with its result/completed events and any error in between. Often this surfaces the actual bug without needing to file an issue.

If the agent can't figure it out either, *that* trace becomes excellent evidence in the bug report — paste both the agent's analysis and the raw event log.

## Frequently asked questions

### What's the difference between filing an issue and asking my agent for help?

Your agent has the structured event log, the project state via `inspectIntegration`, and your full project source. It can fix many issues without escalation — config problems, missing handlers, manifest mismatches, version drift between the generated module and the library. Email when the agent has tried, the trace is conclusive, and the bug is in Extentos itself rather than your project. A "verified Extentos bug" report is far more actionable than an "agent and I are confused" thread.

### How do I send long log files?

Attach event-log dumps to your email as a `.txt` file, or paste a [GitHub Gist](https://gist.github.com) link. Don't paste 5000-line logs inline — they bury the summary.

### Is there a Discord, Slack, or community forum?

No formal community channel at launch. Email is the canonical surface; a public issue tracker / Discussions may open as the user base grows.

### Can I get paid support / consulting?

Not at launch. Extentos is fully self-service today. If a paid support tier ships post-1.0, it will be announced via the [changelog](/docs/resources/changelog).

### What if I want to contribute a fix instead of just reporting?

The development monorepo is private during pre-1.0, so there's no public PR flow yet. If you've got a fix — or a strong opinion on the shape of one — email **[hello@extentos.com](mailto:hello@extentos.com)** with `[contribution]` and the details. External contribution may open up as the project approaches 1.0.

### How do I know if a bug is already known?

Check the [changelog](/docs/resources/changelog) and [status](/docs/resources/status) for recent fixes and known issues first. If it's not there, email it — the reply will tell you whether it's already tracked.

### What if the docs say one thing but the code does another?

The code wins. File a `[docs]` issue with the contradicting doc URL and the source-code path that proves the actual behavior. The maintainers care about doc accuracy because misaligned docs poison AI-agent recommendations downstream.

### Can I email about non-security issues?

Yes — email is the canonical channel pre-1.0. Use [hello@extentos.com](mailto:hello@extentos.com) with the right subject prefix (see [Where to send it](#where-to-send-it)). Security uses the same address with the `[SECURITY]` prefix, handled privately.

## Related

- **[FAQ](/docs/resources/faq)** — most-asked questions, often resolved without filing
- **[Security](/docs/resources/security)** — what we collect, what we don't, end-user privacy guarantees
- **[Changelog](/docs/resources/changelog)** — release history, what's been fixed
- **[Auth](/docs/mcp-server/auth)** — `whoami`, `logout`, install state and identity
- **Packages** — [`@extentos/mcp-server`](https://www.npmjs.com/package/@extentos/mcp-server) (npm) · [`com.extentos:glasses`](https://central.sonatype.com/artifact/com.extentos/glasses) (Maven Central) · [swift-glasses](https://github.com/extentos/swift-glasses) (GitHub — Swift package)