Trust & Transparency

How it loads

You install RuneLite from runelite.net        (we never touch this)
                  │
                  ▼
RuneLite starts a Java VM
                  │
                  │  JAVA_TOOL_OPTIONS tells the VM to load
                  │  ~/.runelite/pluginscape-agent.jar
                  ▼
Agent runs for ~10 ms, flips one switch: "load the sideload folder"
                  │
                  ▼
RuneLite loads ~/.runelite/sideloaded-plugins/pluginscape-<key>.jar
                  │
                  ▼
Your plugins appear in RuneLite's normal plugin list and sidebar

JAVA_TOOL_OPTIONS is a standard, documented JVM environment variable. Profilers, APM agents and debuggers have used the same mechanism for twenty years. It is not an exploit, an injection, or a patched binary.

The one thing we modify, in memory only

RuneLite ships with sideloading behind a developerMode flag. Our agent rewrites that single flag check inside RuneLite's PluginManager class as the class is loaded into memory, so the sideload folder gets read. That is a bytecode transformation, and we'd rather say so plainly than have you find it in a decompiler.

What that means concretely:

• One method in one class, changed in RAM, for the lifetime of that one process.
• Nothing on disk is written, patched, or replaced. Your RuneLite install is byte-for-byte untouched, and always has been.
• If RuneLite changes and the flag check isn't where we expect, the agent leaves the class alone and logs a warning rather than guessing. Worst case: your plugins don't load. It cannot break your client.

What the installer changes on your machine

Full list, nothing omitted:

The honest caveat on JAVA_TOOL_OPTIONS: it is set for your whole user account, not just RuneLite, so every Java application you launch will load our agent and print one [Pluginscape] Agent loaded line. In any process that isn't RuneLite the agent does nothing at all. It waits for a RuneLite class that never arrives, then exits with the process.

The uninstaller reverses all three rows: it clears the environment variable and LaunchAgent, deletes the agent JAR, and deletes pluginscape-*.jar from the sideload folder. Other sideloaded plugins are left alone. No registry keys survive, no scheduled tasks, no services.

1. License check: POST /api/licenses/check

Sent to api.pluginscape.com once when RuneLite starts, then every 15 minutes. This is the only call that carries anything identifying you.

{
  "license_key":      "your license key",
  "hwid":             "sha256 hash of your machine's OS-assigned UUID",
  "legacy_hwid":      "same, older formula, kept only for migrating existing installs",
  "installed_sha256": "sha256 of the plugin JAR you're running"
}

The reply tells the plugin which plugin slugs you own, whether a newer build exists, and that build's version, hash and release notes. Nothing else is sent: not your OSRS account, not your character, not what you're doing in game.

2. Update download: GET /api/releases/download

Only fires when the license check reports a newer build. Sends your license key to prove entitlement, and nothing else. Receives a JAR, which is then checked against the SHA-256 the license check provided and discarded on mismatch.

3. Discord bot-stop alerts (off by default)

If you turn on “Send to Discord” and paste your own webhook URL, a one-line embed is posted to your channel when a bot stops (for example “Out of food”, plus the bot's last state). The webhook URL is validated to be a discord.com domain before posting. It is treated as a credential: never logged, never in telemetry.

4. Public game-data lookups

Some bots need a live item price. Those requests go to the public OSRS Wiki price API (prices.runescape.wiki) and, in one older code path, ge-tracker.com. They contain an item ID and nothing else: no key, no HWID, no account. One world-selection helper opens a TCP connection to an OSRS world to measure ping. These are inherited from the open-source Microbot automation library the plugins are built on.

That is the complete list. There is no fifth endpoint. RuneLite itself makes its own network calls (world list, item prices, hiscores, its own updates) exactly as it always has. Those aren't ours and we don't alter them.

What the plugin does NOT do, specifically

• No keylogging. The plugin sends synthetic key and mouse events into the game canvas; it does not read your input. No global hook, no KeyListener on anything but the game canvas, no capture of what you type.
• No screen capture. Nothing takes a screenshot.
• No clipboard reading. The only clipboard call in the codebase writes test output when you click a “copy” button. Nothing ever reads your clipboard.
• No filesystem scanning. The plugin reads and writes exactly two directories: ~/.pluginscape/ (its own telemetry) and ~/.runelite/ (its own JAR and RuneLite's log folder). It never enumerates, indexes, or uploads anything else.
• No OSRS credentials. Your username and password are typed into RuneLite by you and stay inside RuneLite. The auto-login helper presses Enter on the login screen; every call site passes an empty username and password. Nothing reads, decrypts, stores, or transmits your account details.
• No wallet, browser, or OS data. We don't read browser profiles, crypto wallets, documents, or anything outside the two folders above.
• No usage analytics. We don't know which bots you run, how long you run them, or how much GP you make. The license check carries a key and a machine hash, nothing more.

Telemetry: local-only

The plugin records what a bot did (state transitions, inventory changes, XP gains, errors) to ~/.pluginscape/runs/<bot>-<timestamp>.jsonl, and streams the same events to 127.0.0.1:8777 for the local run dashboard. Both are on by default.

None of it is uploaded. There is no telemetry endpoint on the server; the code to send it does not exist. The WebSocket is bound to 127.0.0.1, which is not reachable from your network, let alone the internet. Your license key is redacted from these files before they're written.

Both switches are in the plugin's Telemetry settings. Turn them off and the files stop being written.

How the hardware fingerprint works

The fingerprint (HWID) is a SHA-256 hash of the machine ID your operating system already assigns itself:

• macOS: Hardware UUID
• Windows: MachineGuid (from the registry)
• Linux: /etc/machine-id

It is a one-way hash: we cannot reverse it into your serial numbers, and we don't collect the components it's derived from.

The first machine you run it on takes a slot. The second takes the other. A third gets a clear “device limit reached” message rather than a silent failure.

Docks, VPNs and new network adapters do not burn a slot. We dropped MAC addresses from the fingerprint precisely because they drifted and cost people slots.

What our licensing database knows about you

Your license key and hardware hash are never linked to a RuneScape account, because we never receive one.

On IP addresses

The license API is a web server, so your IP appears in its request logs and is used to rate-limit abuse (20 license checks per minute per IP). It is not stored in your license record and is not linked to your HWID or your plugins.

If our server goes down

Your plugins keep working. When a license check fails to reach the server, whether that's the server being down, your internet dropping, or us fumbling a deploy, the plugin keeps your last known entitlements instead of assuming you own nothing. This is deliberate: an outage on our side must never lock a paying customer out of software they bought.

Why Wednesday game updates usually don't affect you

You're running the official RuneLite client. When Jagex ships a game update (usually Wednesday morning), RuneLite's own launcher updates RuneLite automatically. We are not in that path, we cannot delay it, and we cannot break it.

A game update doesn't automatically break plugins. It breaks them when the underlying API surface the bots are built on shifts: new widget IDs, changed interfaces, moved objects. That happens some weeks and not others.

When there is an update

1. The license check the plugin already makes (startup, then every 15 minutes) includes the SHA-256 of the JAR you're running. The server compares it to the current release.
2. If a newer build exists, the plugin downloads it automatically in the background.
3. The download is verified against the SHA-256 from step 1 and deleted if it doesn't match, so a corrupted or tampered file can never be installed.
4. The verified JAR replaces the one on disk. On Windows the running JAR is file-locked, so it's staged next to it and swapped in by the agent at the next launch.
5. The Pluginscape panel in RuneLite's sidebar shows installed version, latest version, release notes, and download progress. It says “Restart RuneLite to apply” when a new version is staged.

You never re-download anything by hand, and you never re-run the installer for a normal update.

Check the hash

macOS / Linux:

shasum -a 256 ~/.runelite/sideloaded-plugins/pluginscape-*.jar

Windows (PowerShell):

Get-FileHash "$env:USERPROFILE\.runelite\sideloaded-plugins\pluginscape-*.jar" -Algorithm SHA256

Compare the output against the published hashes below.

Watch the traffic

Use Wireshark, Little Snitch (macOS), or Fiddler (Windows) and filter for api.pluginscape.com. You should see requests at startup and approximately every 15 minutes. You should not see any other Pluginscape domains.

Published release hashes