#Connections

Start with “Are there any Lynx pages I can debug on my phone?” and follow the agent as it loads the instructions, discovers the app, and finds a page.

# Discover the bundled skills and find lynx-devtool for device debugging.
agent-lynx skills list

<available_skills>
  <skill>
    <name>lynx-devtool</name>
    <description>Use when working with Lynx DevTool or debugging a Lynx app, page, or device…</description>
    <location>/workspace/node_modules/@lynx-js/skill-lynx-devtool/SKILL.md</location>
  </skill>
  <!-- Other skills omitted. -->
</available_skills>

# Load the instructions and get the skill directory and reference file list.
agent-lynx skills get lynx-devtool

<skill_content name="lynx-devtool">
Use the `agent-lynx` CLI. The published package is `agent-lynx`.

<!-- Instructions omitted. -->

Skill directory: /workspace/node_modules/@lynx-js/skill-lynx-devtool
Relative paths in this skill are relative to the skill directory.

<skill_resources>

  <file>references/troubleshooting/index.md</file>
  <!-- Other resources omitted. -->
</skill_resources>
</skill_content>

// Read the discovery guide relative to the directory returned by skills get.
Read("/workspace/node_modules/@lynx-js/skill-lynx-devtool/references/troubleshooting/index.md")

## Discovery Model

In practice:

- one client usually corresponds to one app process such as `LynxExplorer`
- one session corresponds to one Lynx page inside that client
- one device may have multiple clients
- one client may have multiple sessions

# Discover apps through the local daemon. The returned id is the client ID for subsequent calls.
agent-lynx list-clients

[
  {
    "id": "android-phone:8901",
    "info": {
      "App": "LynxExplorer",
      "deviceModel": "Pixel 8",
      "osType": "Android"
    }
  }
]

# Use the client ID from the previous result. Each session_id identifies a debugging context in that app.
agent-lynx list-sessions --client android-phone:8901

[
  {
    "session_id": 1,
    "type": "lynx",
    "url": "https://example.com/settings.lynx.bundle"
  }
]

#From an App to a Page

A device can run several Lynx apps, and an app can contain several pages. The conversation identifies the target in two steps:

• Client: choose the app. list-clients returns app names, device information, and client IDs. This example finds Lynx Explorer on the Android phone.
• Session: choose the page. list-sessions returns the app's debugging contexts and page URLs. Select a target with type set to lynx and keep its session_id.

Use both returned IDs for subsequent page operations so the agent acts on the page you intend. Discover the targets again after restarting the app or reopening a page.

#Make Your App Discoverable

Run Lynx Explorer or your own app with DevTool integrated, enable Lynx Debug and Lynx DevTool, and open a Lynx page. The example starts from this state. For other platforms, see device connection setup.

If discovery is incomplete, continue the conversation:

The agent can wait for an app, open a bundle URL, and choose a target using the device, app name, and page URL. Run the project's development server separately and make sure the app can reach the bundle URL.

#How Calls Stay Connected

Device commands automatically start the local agent-lynx daemon. It keeps device connections and snapshot refs across CLI calls, letting the agent continue from discovery to inspection, actions, and verification. See the architecture diagram in the introduction.

Next, ask the agent to inspect and operate on the page or take a screenshot. Connection timeouts, daemon ports, and direct mode are documented in the CLI reference.