Support

Extentos is pre-1.0. Bugs and feature requests go in the public GitHub issue trackers, anything private goes to email, and 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 report. This page is where to start when something goes wrong.

Where to send it

Bugs, feature requests, and documentation errors go in the GitHub issue tracker for the component you hit. Public issues are searchable, so the next developer to hit the same thing finds your report instead of filing it again.

Not sure which one owns it? File on any of the three and it gets moved. The component triage table below is the rule of thumb if you'd rather route it yourself. The bug template asks for the same six things listed in what to include.

Some things don't belong in a public tracker. For those, use the contact form, which lands in the inbox already tagged and with your reply address attached, or email hello@extentos.com with a subject prefix:

No GitHub account, and no wish to make one? Email the bug with the [bug] prefix and the checklist below, and it gets filed for you.

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

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

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:

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:

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 (npm, MIT)
• Android library — com.extentos:glasses (Maven Central)
• iOS library — Extentos (Swift package, swift-glasses on GitHub) — pin the version as shown in the iOS install guide

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. The GitHub bug template asks for exactly these, so filing there gets you the checklist for free.

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:

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 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, 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 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 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:

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. File once 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?

In an issue, put the log inside a collapsed <details> block or link a GitHub Gist. Over email, attach it as a .txt file. Don't paste 5000-line logs inline — they bury the summary. Redact tokens and credentials before posting anything publicly: a Meta Client Token or an Extentos auth token in a public issue is a live secret.

Is there a Discord, Slack, or community forum?

No Discord or Slack at launch. The closest thing to a community surface is the GitHub issue trackers listed in where to send it: they're public and searchable, so a filed bug is visible to everyone else building on the same SDK. A chat channel 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.

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, open an issue on the component's tracker and describe it there, or email hello@extentos.com with [contribution]. Either way it gets applied in the monorepo with attribution in the changelog. External PRs may open up as the project approaches 1.0.

How do I know if a bug is already known?

Search the tracker for the component that owns it, then check the changelog and status for recent fixes and known issues. If it's in none of the three, file it. A duplicate is cheap to close, so err toward filing.

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

The code wins. File on extentos/mcp-server 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 reaches a human for anything, and it's the right channel for anything you'd rather keep private: billing, account, security, or a report you don't want public. For a plain SDK bug, a GitHub issue is the faster path, because it's searchable and gets closed against the release that fixes it. Use hello@extentos.com with the right subject prefix (see Where to send it). Security uses the same address with the [SECURITY] prefix, handled privately.

Related

• FAQ — most-asked questions, often resolved without filing
• Security — what we collect, what we don't, end-user privacy guarantees
• Changelog — release history, what's been fixed
• Auth — whoami, logout, install state and identity
• Packages — @extentos/mcp-server (npm) · com.extentos:glasses (Maven Central) · swift-glasses (GitHub — Swift package)