siva010505/xenon

Purpose and operating model

XENON is a Windows-focused AI browser assistant for a user-launched Chrome instance. A Chrome side-panel extension collects tasks and settings, then reaches Python automation services that control or inspect the host browser through its debugging-enabled session. Setup scripts provision dependencies, native messaging registration, and the dedicated Chrome launch profile.

Key entry points: setup.bat, Launch_Xenon_Chrome.bat, server.py, and extension/manifest.json.

Chrome extension UI and lifecycle

The extension is the user-facing boundary. Its side panel hosts task interaction and settings/personal-information capture; speech support is a separate extension page. A background/service-worker layer manages extension lifecycle and communication outside the side-panel document.

Core paths:

• extension/sidepanel.html

• extension/sidepanel.js

• extension/service-worker.js

• extension/speech.js

Native messaging bridge

Chrome native messaging provides a local process boundary between the extension and Python. The extension declares a native host, while the bridge reads/writes the native-messaging protocol and can mediate requests to local automation/server processes. Windows installation scripts register the host manifest with Chrome.

Core paths:

• extension/com.xenon.server.json

• extension/host/manifest.json

• extension/host/bridge.py

• native_host.py

Python server and agent orchestration

The Python backend is the control plane for requests originating from the extension/native host. It selects and runs AI-driven browser automation workflows, including general browser-use tasks and deeper research workflows. Agent code is separated from browser primitives so task strategy can evolve independently of Chrome connection details.

Core paths:

• server.py

• src/agent/browser_use/browser_use_agent.py

• src/agent/deep_research/deep_research_agent.py

• src/controller/custom_controller.py

Browser automation boundary

Browser integration is encapsulated in custom browser and context modules. This is the boundary where agent decisions become browser actions—navigation, DOM/vision-based interaction, extraction, and form completion—against the debugging-enabled Chrome session rather than an extension-owned page model.

Core paths:

• src/browser/custom_browser.py

• src/browser/custom_context.py

• Launch_Xenon_Chrome.bat

LLM, configuration, and tool integration

Agent execution is provider-agnostic: LLM provider selection and runtime configuration are centralized in utilities, supporting cloud and local model providers named in the project documentation. An MCP client indicates an additional external-tool/protocol integration boundary available to agents.

Core paths:

• src/utils/llm_provider.py

• src/utils/config.py

• src/utils/mcp_client.py

• requirements.txt

Runtime and deployment assumptions

The material runtime is Python 3.11+ on Windows, Chrome with a dedicated debugging profile, and extension APIs/native messaging. Setup installs Python and browser-automation dependencies, configures a hidden/background launcher, and registers native-host integration. External services are the user-selected LLM APIs or local Ollama endpoint; credentials are supplied through the extension settings flow.

Core paths:

• setup.bat

• setup_helper.py

• register_native_host.bat

• start_xenon_silent.vbs