# Use Device Context | EasyNet Docs

Source: https://easynet.run/docs/connect/context

Docs / Use device Context
[Docs](https://easynet.run/docs)

Docs

# Use device Context

Keep references to project folders, clipboard items, and favorites on your device. The guide separates local collection from agent access.

Map a folder or explicitly opt into clipboard capture on this device so Context Abilities can retain device-scoped references.
[All connection paths](https://easynet.run/docs/connect)

## Run this guide

Outcome

Map a folder or explicitly opt into clipboard capture on this device so Context Abilities can retain device-scoped references.

Before you run it

The public CLI can add and list local Context without an account or daemon. Folder mapping grants bounded local read access. `clipboard on` only stores an opt-in flag: actual capture requires a running daemon, and the current clipboard reader is implemented on macOS; Linux and Windows remain idle.
[Install the CLI first — local mapping needs no pairing](https://easynet.run/docs/connect/runtime?continue=context#run-guide)

### Give your coding agent the whole setup task

Includes the selected mode, prerequisites and checks. Copying does not run anything. Context tasks cover folder mapping only; Windows installation remains on hold.

Preview task
zsh · map and inspect Context

```
easynet context add /absolute/path/to/project --name project
easynet context list
easynet context clipboard status
```

Optional: capture clipboard history on macOS

Folder mapping does not require clipboard capture. Only enable this if you want the running daemon to retain copied content on this device; copied secrets may be captured too. The current reader works on macOS, not Linux or Windows.
Enable clipboard capture

```
easynet context clipboard on
easynet context clipboard status
```

Stop future capture

```
easynet context clipboard off
easynet context clipboard status
```

Turning capture off changes the tracking setting; it does not delete previously stored clips. The daemon observes the setting asynchronously, so stopping is not an immediate purge.

## Verify the result and boundary

Success looks like

`context list` prints the mapped folder. `context clipboard status` confirms the stored opt-in state and clip count; on macOS, an increasing count while the daemon runs is the separate evidence that capture is active.

Still separate

An enabled flag alone is not capture evidence, especially on Linux or Windows. Clipboard and capture use internal, device-scoped Context references; they are not canonical Resource URAs, and local capture does not make them Realm-visible.

### Next: let an agent browse the mapped folder

The commands above prepare this device only. For a local coding client such as Codex, follow EasyNet → Codex and its paired Runtime prerequisites. This same-device connection uses the local Runtime identity; it does not create a separate Codex caller or prove isolation between clients. Mapping a folder does not grant access or publish a tool automatically.

Find the tool whose x-easynet.ability is context.folders.list in the MCP tools/list response; its description also identifies the Ability. Call the returned tool name, not an assumed dotted name. The result should include your mapped folder name.

Find the tool for context.fs.list in the same way. Call its returned name with folder set to your mapping name and path set to an empty string. Compare the returned entries with your chosen directory.

This verifies directory browsing, not file-content reading, semantic search, or automatic import of conversations. These are Runtime source contracts, not a completed cross-device test. If a tool is missing or a request is denied, check the specific error, Runtime status, and mapped path. A path-boundary rejection is not proof of caller-policy isolation. Do not broaden the mapping to bypass a rejection.

#### Tested with a real local Runtime

A protocol client discovered both Context tools and listed a synthetic project directory. The hidden entry was excluded; a request outside the mapping was rejected.

Returned directory entries

```
[
  {
    "name": "readme.txt",
    "kind": "file"
  },
  {
    "name": "subdir",
    "kind": "dir"
  }
]
```

Historical development test, 6 September 2026. One physical host; a deterministic MCP client, not Codex or an LLM. This does not prove cross-device execution or permission isolation between clients.
[Inspect the test summary (JSON)](https://easynet.run/evidence/context-mcp-2026-09-06.json)[Connect your coding client](https://easynet.run/docs/connect/mcp?continue=context)[Get help verifying agent access](https://easynet.run/pilot)

Recorded workflow · 6 September 2026

### From a directory listing to a handoff manifest.

An assistant queried a mapped folder through Context, then passed the returned metadata to an EasyRemote function. Two kinds of capability contributed to one result.

01

Find the project mapping
context.folders.list

02

List its directory entries
context.fs.list

03

Send the metadata to the function
handoff.summarize_inventory

#### Returned manifest

file

1

directory

1

listed file bytes

59

subdir/ · readme.txt

Synthetic same-device test. One local Runtime identity; no file contents read. This counts the listed entries, not every file in a project.

How this was recorded

The assistant selected each call through a restricted stdio bridge after seeing the previous response. It knew the fixture and formatter source. This was not native coding-client MCP setup, a blind benchmark, a customer workflow, or a cross-device test. The formatter was built for this demonstration. Trace fields were not independently signature-verified.
[Download the scoped record (JSON)](https://easynet.run/evidence/context-function-2026-09-06.json)