Support

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 — 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 with a subject prefix so it routes fast:

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

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.

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. 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 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.

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 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 and 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 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)

Related