Driving a real client (BeDD)

bedboo normally is the client: it logs in to Bedrock Dedicated Server over RakNet or NetherNet and sends every packet itself. With transport: 'bedd' it drives a real Minecraft Bedrock 1.26.51.01 client instead, hosted by Be.D.D. (Bedrock Deep Dive, a LeviLamina client mod). The same script then runs against the game window on your desk: you watch the local player walk, look, dig, place and chat as the script says.

const bedboo = require('bedboo')
const bot = bedboo.createBot({ transport: 'bedd', bedd: { pipe: '\\\\.\\pipe\\BeDD' } })
bot.once('spawn', () => bot.chat('hello from bedboo'))

Choosing between the modes is only transport; direct BDS mode (raknet, nethernet) is unchanged. The differences of this mode, entry by entry: BeDD mode.

Setup

Windows only (BeDD's pipes are Windows named pipes); Node 24 or later.

1. Install BeDD into a Minecraft Bedrock 1.26.51.01 instance (see the BeDD docs; clone-instance.ps1 makes a separate instance, Start-BeDDGame.ps1 -Instance <name> starts it).

2. Turn the bedboo features on in the instance's mods\BeDD\config\config.json. Every one of them is off by default:

   key	default	what it enables	bedboo needs it for
   pipeName	BeDD	the control pipe \\.\pipe\<pipeName>; the tap pipe is \\.\pipe\<pipeName>-tap	bedd.pipe (the tap name is derived)
   tap	false	the tap pipe: every clientbound packet, an echo of every serverbound packet, markers, a join journal	everything (without it bedboo cannot attach)
   tapLoopback	true	tapping singleplayer / LAN-host worlds (loopback link, re-serialized packets)	singleplayer
   tapJournalMiB	128	size cap of the join journal replayed to a late attach	attaching mid-session (complete:false past the cap)
   gameHooks	false	the world, look and input ops (hooks in the game's own input pipeline)	precise movement and looking (without it: virtual keys and mouse)
   allowSend	false	the send op for the allowlisted packet ids (sendAllow, default [9, 77] = text, command_request)	bot.chat, whispers, commands
   allowStack	false	the stack op: item_stack_request submitted through the client's own ItemStackNetManager	inventory: clickWindow, transfer, craft, deposit/withdraw, equip from the main inventory, creative
   pipeInstances	4	how many control-pipe clients may be connected at once	bedboo next to BeDD.psm1 and other harnesses

   A config for bedboo:

   json

   { "pipeName": "BeDD-1.26.51.01-hi20", "tap": true, "tapLoopback": true, "gameHooks": true,
     "allowSend": true, "allowStack": true, "pipeInstances": 4, "loopbackOnly": true }

   loopbackOnly (BeDD's own key) keeps the client on servers of the same PC (127.0.0.1). The client joins BDS 1.26.51 over NetherNet, so start the server with transport=nethernet; NetherNet joins go through Minecraft's online signalling service, so no other Minecraft game on the PC may start while the client joins and plays (a later sign-in knocks the session out: "Multiplayer Connection Failed … NetherNet").

3. Start the game and get the player into a world (a server, a LAN world or singleplayer): bedboo attaches to a client that is already playing, it does not log in.

4. createBot({ transport: 'bedd', bedd: { pipe: '\\\\.\\pipe\\BeDD-1.26.51.01-hi20' } }). spawn fires once the join journal has been replayed; from then on bot.* is the client's state.

The bedd_follow.js example makes the client follow the nearest other player:

node examples/bedd_follow.js --pipe \\.\pipe\BeDD-1.26.51.01-hi20

How it works

The real client stays authoritative for everything it sends: login, resource packs, the loading screen, chunk requests, player_auth_input every tick (physics included), block actions, inventory transactions and item stack requests. bedboo never forges those packets. Its whole stack still runs, and what it would have sent becomes an intent for the client:

script → mineflayer API → plugins → _client.queue → router ──(JSON ops)──────→ \\.\pipe\<pipeName>     → the game's input pipeline
bot.* state ← plugins ← decoder ← tap reader ←──(binary frames)──── \\.\pipe\<pipeName>-tap ← every packet the client gets / sends

• State in: the tap pipe carries every clientbound packet the client receives, an echo of every serverbound packet it sends, and JSON markers (HELLO, LINK_UP/LINK_DOWN, REPLAY_BEGIN/REPLAY_END, DROPPED). bedboo decodes them with bedrock-protocol exactly as in direct mode, so bot.entities, the world, inventory, chat and every event come from the real session. A join journal (since start_game, compacted: the latest chunk per position, the latest attributes per entity, removed entities pruned) is replayed to every new tap client, so bedboo can attach mid-session. If bedboo falls more than 32 MiB behind, BeDD sends DROPPED and closes; bedboo reconnects and gets a full replay.
• Self state: bot.entity position, velocity, yaw, pitch and onGround follow the echoed player_auth_input (eye − 1.62). physicsTick and move fire once per client tick; bedboo's own physics engine does not step.
• Intents out: a router diffs what bedboo would have sent and calls BeDD's control ops: input (move vector, jump, sneak, sprint, with a dead-man TTL), look (absolute yaw/pitch), slot, button (attack/use/pick, released on block change for digging), action (drop, inventory, …), send (allowlisted text/command_request bytes) and stack (item_stack_request through the client's ItemStackNetManager). Input is applied only while the game has the mouse and shows no menu.
• Negotiation: at attach, bedboo pings the control pipe and probes each op with no arguments: unknown op → absent, code:'disabled' → present but turned off in config.json, ok → present. bot.bedrock.bedd.caps holds the result and bot.bedrock.bedd.supports(name) answers per mineflayer API.

Authority table

Coverage

"Caps" names the BeDD ops the API needs; without them bot.bedrock.bedd.supports(name) is false and the call throws or rejects with ERR_BEDD_UNSUPPORTED (or uses the stated fallback).

Notes: activateItem(true) (off-hand) uses the main hand, the client has no off-hand use button; activateItem of an item that is not used by holding (throwables, a fishing rod) is one click; bot.respawn() is a no-op with a warning (the user clicks Respawn, so respawn: true never throws from the health listener); bot.craft keeps upstream's new Error(err) wrapping, so check err.message there when the surface did not refuse it first.

Degraded: pathfinder sees 1-2 ticks of lag (prediction is overwritten by the echo); the client's own raycast decides what a click hits, so an action can land on an adjacent block or entity (bedboo sees it on update_block / entity events); flight via a double-tap jump; input pauses while a screen is open; a late attach depends on the journal (complete:false → chunks missing until re-entered); a world change on the client ends the bot (LINK_DOWN).

Singleplayer and LAN worlds

With tapLoopback (on by default once tap is), BeDD also taps a world the client hosts itself: singleplayer or a LAN world. Those packets never hit the network, so BeDD re-serializes them (Packet::write, frame flag reserialized) and filters them to the local player, so LAN guests' traffic is not mixed in. Everything in the coverage table works the same; the HELLO marker says link.type: 'local'.

Security

• The tap exposes the session. A tap client reads everything the logged-in player sees and does: chat, positions, inventory, the world. The tap pipe accepts one local client of the current Windows user (PIPE_REJECT_REMOTE_CLIENTS, current-user DACL), and it only exists when tap is on.
• send and stack act as the account. send posts chat and commands as the logged-in player, stack moves its items. Both are off by default (allowSend, allowStack); send is limited to the sendAllow ids ([9, 77]), and login, player_auth_input, item stack and similar ids (1, 30, 144, 147) are always refused.
• Turn these on only in instances you use for automation, and never let a manager or remote tool toggle them.

Options and bot.bedrock.bedd

createBot({ transport: 'bedd', bedd: { pipe, tapPipe?, connect?, timeoutMs?, modules? } }):

• bot._bedrock.mode === 'bedd'.
• bot.bedrock.bedd.caps: { [op]: 'present' | 'disabled' | 'absent' } for tap, world, look, input, slot, button, action, send, stack (and the protocol-1 ops key, text, mouse, raw, … once ping answers). Without a control pipe every op is absent and the bot only observes.
• bot.bedrock.bedd.supports(name): whether a mineflayer API ('dig', 'craft', 'creative.setInventorySlot') or a BeDD op works with these caps.
• bot.bedrock.bedd.observed: { yaw, pitch, tick } of the last echoed player_auth_input, null before the first.
• Errors: BeddUnsupportedError (code: 'ERR_BEDD_UNSUPPORTED', bedd: true, feature, missing); an unsupported packet also emits 'bedd_unsupported_packet' { name, feature } on bot, once per name.
• Client events besides the usual ones: 'serverbound' { name, params, reserialized } (what the client sent), 'bedd_marker' (tap markers) and 'warning' (a packet that did not decode; the stream goes on).

Roadmap

• A drive / puppet mode (suppress, inject and pin the pose), once pinning is shown to survive client reconciliation.
• Screen-level ops: the respawn button, signs and books.
• A connect op so bedboo can make the client join a given server.
• A second split-screen subclient.