Levandor

reMarkable Paper Pure ↔ Claude Code integration — evaluation (device NOT purchased)

11 min read

Forward-looking evaluation of live-integrating a reMarkable Paper Pure tablet with Claude Code and telep-mainframe. The device is not bought. This note exists so the work can be picked up cold on the day it arrives, without re-running the research.

STATUS: PLANNED — nothing here has been executed

No hardware, no install, no service. Every command, path and IP below is from vendor/project documentation, not verified on a device in this house. Treat it as a research brief, not a runbook. When the tablet arrives and this is actually done, write a type/runbook note and downgrade this one.

Verdict

Easy. A mature MCP server already exists — remarkable-mcp — that exposes a reMarkable library to MCP clients (Claude Code, VS Code Copilot, OpenWebUI). MIT licensed, run via uvx remarkable-mcp (needs uv), built on rmscene + PyMuPDF + markdown-it-py.

Paper Pure is supported. reMarkable’s own tooling and docs group Paper Pro / Paper Pro Move / Paper Pure together throughout, and rmfakecloud lists Paper Pure explicitly.

READ THIS BEFORE THE BOX IS OPENED — enabling Developer Mode FACTORY-RESETS the tablet

Unlike the rM1/rM2 (which shipped with SSH available out of the box), Paper Pro / Paper Pro Move / Paper Pure all require Developer Mode before SSH works — and turning Developer Mode on wipes the device.

Therefore: decide on SSH mode BEFORE putting anything on the tablet, and enable Developer Mode on day one, straight out of the box. Doing it later costs everything on the device, or a full cloud round-trip to get it back.

  • Path on device: Settings → General → Paper Tablet → Software → Advanced → Developer Mode
  • Credentials afterwards appear in a deeply unintuitive place: Settings → General → Help → About → Copyrights and Licenses, under the “GPLv3 Compliance” header — username root, a random password, and the device IP addresses.
  • reMarkable warns against storing sensitive data on a device in Developer Mode.
  • Exiting Developer Mode requires the recovery process.

The four transport modes

remarkable-mcp can reach the library four different ways. This table is the decision.

ModeSetupSubscriptionOfflineTablet neededUploadFolder ops
Local directoryDesktop app installedNo (app syncs)YesNoNoNo
USB webEnable in Settings → StorageNoYesYes (plugged in)Root folder onlyNo
CloudOne-time registration codeConnect subscription requiredNoNoYesYes
SSHDeveloper mode (factory reset)NoYesYesYesYes

Invocation:

uvx remarkable-mcp --usb            # USB web interface
uvx remarkable-mcp --local-dir <p>  # reMarkable desktop app's synced folder
uvx remarkable-mcp                  # cloud (default)
uvx remarkable-mcp --ssh            # SSH / developer mode

Flags that matter:

  • --read-only — disables every write tool.
  • --http — serve Streamable HTTP instead of stdio (see the security section, this is the risky one).
  • --register <CODE> — one-time cloud registration.

Cloud registration flow: get a code at my.remarkable.com/device/desktop/connect, then

uvx remarkable-mcp --register YOUR_CODE   # saves a token to ~/.rmapi

SSH specifics worth recording

  • USB gives ethernet-over-USB at 10.11.99.1 → ssh root@10.11.99.1.
  • SSH over WiFi is DISABLED by default. Enable it with the on-device rm-ssh-over-wlan utility, which sets a flag on the home partition.
  • /home is freely writable. The root partition must be remounted rw to modify the OS, and reverts to read-only on reboot. Getting this wrong can leave the tablet unbootable.
  • Prefer key auth: append your pubkey to /home/root/.ssh/authorized_keys, chmod 600.

Why SSH mode is the interesting one — remarkable_author

SSH is the only mode that exposes remarkable_author, and that is the whole reason to consider the destructive path. It lets Claude write native ink onto the device:

  • draw — append pen/highlighter strokes; coordinates normalized [0,1].
  • add_page — append a blank notebook page.
  • create_document — create a new notebook.

Results are byte-identical to what the interactive canvas’s Save button produces, because both call the same tool. Every other transport can only upload PDFs/EPUBs — those land as imported documents, visibly not handwriting.

The SSH backend also carries engineering care worth knowing before debugging it:

  • Writes are FIFO-serialized through a single dispatcher.
  • Concurrent writes share one xochitl restart barrier.
  • defer_restart=True + a trailing remarkable_refresh() batches a bulk import into one restart.
  • Retries are deliberately narrow — only failures that prove the remote command never started are replayed.

Tool surface

Read tools: remarkable_read, remarkable_browse, remarkable_search, remarkable_recent, remarkable_status, remarkable_image (PNG/SVG, optional OCR), remarkable_export (PDF or sectioned Markdown).

Write tools (on by default on write-capable transports): remarkable_upload, remarkable_markdown_to_pdf, remarkable_mkdir, remarkable_move, remarkable_rename, remarkable_delete, remarkable_refresh (SSH), remarkable_author (SSH).

Also: remarkable_canvas — an MCP Apps interactive page viewer, always registered; app-capable clients get a side panel, everything else just gets the rendered PNG.

Documents auto-register as MCP resources under remarkable:///, remarkableimg:///, remarkablesvg:/// etc.

REMARKABLE_ROOT_PATH scopes the server to a single folder (e.g. /Work) — the natural way to keep work and personal separate, and the natural way to give a homelab agent a narrow blast radius.

OCR — the part that decides whether handwriting is actually usable

Handwritten notes are pixels; an LLM needs OCR to read them. Backend selected by REMARKABLE_OCR_BACKEND = auto | google | tesseract.

BackendHandwritingOfflineCost
Google VisionGoodNoAPI key; 1,000 free req/month, then ~$1.50/1,000
TesseractPoor (designed for printed text)YesFree

Typed text, PDF text and PDF annotations extract natively — no OCR needed. Only ink needs it.

Implication for the homelab

A “notebook → Claude” workflow over handwriting effectively means sending page images to Google Vision. If that is unacceptable, the realistic fallbacks are typing on the tablet, annotating PDFs (native extraction), or accepting Tesseract’s poor handwriting accuracy.

The self-hosted alternative — rmfakecloud

https://github.com/ddvk/rmfakecloud — host the entire sync backend yourself. No reMarkable cloud, no Connect subscription. This is the most homelab-native option and the one that fits telep-mainframe.

Supported devices include rM1, rM2, Paper Pro, Paper Pro Move and Paper Pure.

Firmware version risk

File sync is tested up to reMarkable software 3.27.1 — newer firmware is untested. A tablet auto-update is therefore a real breakage risk for the whole sync path. Plan for it (hold updates, or accept downtime).

Setup requires installing rmfakecloud-proxy ON the device (so Developer Mode / SSH is a prerequisite here too). For Paper Pro / Paper Pro Move:

scp installer-rmpro.sh root@10.11.99.1:
ssh root@10.11.99.1 'chmod +x installer-rmpro.sh && ./installer-rmpro.sh install'
# rM1/rM2 use installer-rm12.sh instead

What the installer actually does — worth knowing before trusting it:

  1. Generates a CA and a host cert for *.appspot.com.
  2. Places the CA in /usr/local/share/ca-certificates and runs update-ca-certificates.
  3. Edits /etc/hosts to redirect the cloud endpoints at your server.

Then authenticate with a one-time code via Menu → General → Account → Setup Account.

Supported: sync protocol 1.0 and 1.5/2/3/4, send-by-email, handwriting recognition, screen sharing, WebDAV (Nextcloud/Owncloud). Not supported: handwriting search, OneDrive. Dropbox/Google Drive are WIP.

Release-note gotcha — v0.0.25 needs a new /etc/hosts entry

v0.0.25 requires an additional domain in the tablet’s /etc/hosts: eu.tectonic.remarkable.com. Missing it after an upgrade looks like a sync failure with no obvious cause.

This pairs naturally with the existing Nextcloud “Drive” stack on telep-mainframe via rmfakecloud’s WebDAV support — see 2026-08-31-nextcloud-drive-tailscale-spec and the operational 2026-08-31-nextcloud-drive-code-server-runbook. A Drive folder becomes a reMarkable folder, both directions, with no vendor cloud in the path.

Security — how this must be exposed, per house convention

If remarkable-mcp is ever run as a long-lived HTTP service (--http), its README is explicit:

Streamable HTTP has NO built-in authentication.

It binds 127.0.0.1 by default and rejects wildcard binds (0.0.0.0, ::) outright. Remote access is expected to go through an authenticated reverse proxy on the same host that rewrites Host to the loopback upstream and clears Origin. MCPServer’s DNS-rebinding protection returns:

  • 421 Misdirected Request for a forwarded public hostname
  • 403 Forbidden for a public browser Origin

The README ships an nginx example using auth_basic.

Conflict to resolve before deploying: 127.0.0.1 vs the 127.0.0.2 house rule

The house rule from 2026-08-31-tailnet-plaintext-port-hardening is to bind 127.0.0.2, NOT 127.0.0.1, behind tailscale serve — because tailscaled --tun=userspace-networking unconditionally forwards the node’s tailnet IP:port to 127.0.0.1, exposing the backend as plaintext, unauthenticated, to the whole tailnet, beside the TLS front door.

remarkable-mcp’s bind check is loopback-only and its documented default is 127.0.0.1. Verify it accepts 127.0.0.2 before assuming this is deployable under the house convention. If it hard-codes 127.0.0.1, the raw forwarder leak applies and something else (a proxy in front, a non-userspace sidecar, or a patch) must close it.

Also expect the 421 trap already hit twice here — 2026-08-31-telep-kb-mcp-server and drive-mcp in 2026-08-31-nextcloud-drive-code-server-runbook both needed explicit allowed-hosts config to survive tailscale serve. This server’s DNS-rebinding guard is the same class of failure.

Node/hostname pattern: see tailnet-service-exposure-convention (dedicated tailnet node per service), or path-mount onto an existing node the way 2026-09-01-bambuddy-slicer-api-pipelines-mcp mounts /mcp.

Honest limitation — none of this is push

"Live" means "current when queried", not streaming

Every transport is PULL. Claude reads the tablet when asked and is never notified when the user writes something. There is no webhook and no watch mechanism.

  • SSH is the closest to live — files change on the device the moment a page is saved.
  • Cloud / rmfakecloud update when the tablet syncs.
  • Local dir updates when the desktop app syncs.

Anything event-driven (e.g. “notify the agent when I finish a page”) has to be built on top — polling remarkable_recent, or an inotify watch on the SSH/rmfakecloud side.

Recommendation

GoalPickWhy
Fastest zero-risk startUSB webSettings → Storage, then uvx remarkable-mcp --usb. No subscription, no reset, ~10 minutes. Costs: only while plugged in, and upload can’t choose a folder.
Best capability without a subscriptionSSHOnly mode with remarkable_author (native ink). Only viable if Developer Mode is enabled on day one.
Most homelab-nativermfakecloud on telep-mainframeFull sync backend self-hosted, WebDAV into the Nextcloud Drive stack. Caveat: firmware ≤ 3.27.1 tested.
Easiest wireless pathCloudRequires a paid reMarkable Connect subscription.

When the device arrives — do this in order

Step 1 is irreversible-ish and destructive. It goes first for that reason.

  1. DECIDE ON SSH — before anything is written to the tablet. If SSH or rmfakecloud is wanted at any point in the future, enable Developer Mode now, out of the box, while there is nothing to lose. Settings → General → Paper Tablet → Software → Advanced → Developer Mode. Accept the factory reset.
  2. Record the credentials immediately — Settings → General → Help → About → Copyrights and Licenses → “GPLv3 Compliance”: root + random password + IPs. Put them in the password manager, not in this vault.
  3. Consider holding firmware updates if rmfakecloud is the target (tested ≤ 3.27.1).
  4. Prove the concept over USB first — Settings → Storage → enable the USB web interface, plug in, uvx remarkable-mcp --usb, register in Claude Code, call remarkable_status / remarkable_browse. This validates the whole MCP path with zero device risk.
  5. Move to --ssh — USB ethernet ssh root@10.11.99.1 first, then rm-ssh-over-wlan for WiFi, then key auth into /home/root/.ssh/authorized_keys (chmod 600). Test remarkable_author draw on a throwaway notebook.
  6. Set REMARKABLE_ROOT_PATH (e.g. /Work) to scope the agent, and consider --read-only for any always-on instance.
  7. Decide OCR — Google Vision key vs Tesseract vs “typed/PDF only”. This determines whether handwriting is actually readable.
  8. Only then consider rmfakecloud on telep-mainframe: install installer-rmpro.sh on the device, check /etc/hosts includes eu.tectonic.remarkable.com, wire WebDAV to the Nextcloud Drive stack.
  9. If exposing over the tailnet, resolve the 127.0.0.1 vs 127.0.0.2 conflict above before the service goes live, and expect a 421 on first contact through tailscale serve.

Open questions

  • Does remarkable-mcp --http accept a 127.0.0.2 bind, or is its loopback check 127.0.0.1-only? (Blocks tailnet deployment under the house rule.)
  • Is there an allowed-hosts / DNS-rebinding escape hatch equivalent to FastMCP’s allowed_hosts?
  • Does Paper Pure’s firmware track Paper Pro closely enough that installer-rmpro.sh applies unchanged?
  • Current reMarkable firmware vs rmfakecloud’s tested 3.27.1 ceiling at purchase time.
  • Is the Google Vision dependency acceptable, given the rest of this homelab is deliberately self-hosted?

Sources

Graph View

Backlinks