
Every cloud has solved the same problem in its own way: let a verified person reach a server that has **no public IP and no open ports**. Google has [Identity-Aware Proxy](/blog/2026/09/08-reach-google-iap-into-your-cloud-servers-without-the-jump-box/). AWS has Session Manager (SSM) and EC2 Instance Connect Endpoint (EICE). Azure has Bastion. They're all genuinely good, and they all share the same catch at the front end: a different CLI to install, a different login to perform, a different tunnel command to babysit, and a different set of quirks when it goes wrong.

Reach's **Remote Targets** collapse that. A target is just a named server you click Connect on; behind the scenes Reach opens the right identity-aware tunnel for whichever cloud it lives in, and it does so by speaking each cloud's protocol **natively**, with no cloud SDK or CLI bundled into the client.

## The backends

A target is backed by one of five things, and only the config for that backend is populated:

- **`gcp-iap`**: Google IAP. The client opens the IAP TCP tunnel directly to a `project / zone / instance / interface / port`.
- **`aws-ssm`**: AWS Session Manager. Reach runs the Session Manager data channel itself, using **smux over the Message Gateway Service WebSocket**, to reach an instance by ID, in a region, on a port. No `session-manager-plugin`.
- **`aws-eice`**: EC2 Instance Connect Endpoint. A tunnel to an `instance_id` via an `endpoint_id`, signed and opened directly.
- **`azure-bastion`**: Azure Bastion, reaching a `target_resource_id` through a named bastion in a resource group and subscription.
- **`reach-relay`**: Reach's own relay, for the machines none of the clouds can see: the on-prem server, the box in the office cupboard, a contractor's agreed device.

Each target also carries a **proto** (`rdp`, `ssh` or `tcp`) and a **local port**. That's the clean part of the design: once a tunnel is up, it's just a local port, and the launching logic (write the `.rdp` and open mstsc, open a terminal, or hand you `localhost:port` for anything else) is identical across every backend. The cloud-specific code stops at "I have a tunnel"; everything above it is shared.

## Why hand-rolled, no SDKs

Bundling four cloud SDKs (and their transitive dependency trees) into a desktop tray is how you end up with a 200 MB binary that takes a security review a month to approve. Each of these tunnels is, underneath, a reasonably small protocol: a signed request, a WebSocket or a TCP channel, and a framing layer. Reach implements them directly in Go, including the AWS SigV4 signing, the SSM smux framing and the IAP tunnel handshake, so the client stays small, auditable, and free of the cloud vendors' own CLI update treadmill. It also means **one** connection UX and **one** audit trail across all of them, rather than four tools each logging somewhere different.

## Dashboard-managed, so staff don't touch any of this

Targets are **synced from the dashboard**: `GET /api/reach/targets` returns the set, versioned, and the client just renders it. An admin defines "Accounts DB (prod)" once, with its backend and config; everyone who's entitled to it sees a server they can click Connect on. Nobody on staff installs `gcloud`, learns an `aws ssm start-session` incantation, or pastes a resource ID. The messy per-cloud config lives in one place, managed by the person who should manage it.

## The honest notes

- **Cloud-native targets use that cloud's identity.** An IAP-backed or SSM-backed connection is still authorised by your Google / AWS / Azure identity, which is usually exactly what a shop already standardised on that cloud wants. The "give a contractor access without adding them to your directory" trick applies to **`reach-relay`** targets, not the cloud-native ones. Reach is honest about which is which.
- **Each backend needs its IAM set up.** Reach carries the connection; it doesn't grant the permission. The GCP instance still needs its firewall open to the IAP range and the user bound to the right role; the AWS instance needs the SSM agent and an instance profile; and so on. A subtle one worth knowing on GCP: **`resource.name` IAM conditions do not gate IAP TCP tunnels**. You have to gate on `destination.ip`/`destination.port`, or the tunnel authorises when you didn't expect it to.
- **It's for your servers.** Targets are destinations an admin has deliberately provisioned. This is zero-trust access to a managed fleet, not ad-hoc discovery of random hosts.

The pitch is the same one each cloud makes for its own proxy, namely reaching a server with no public IP, gated by identity, but told once, across all of them, from a client that a non-engineer can actually use. **IAP for the Google box, SSM or EICE for the AWS box, Bastion for the Azure box, Reach's relay for everything else, and the same Connect button for all four.**

*Remote Targets are part of TYO Reach. [Start here](https://reach.tyo.com.au), or go straight to the [download](https://reach.tyo.com.au/download).*


0ab09bff2f21348c3a0ce3156a04e113f3f825fdeb9732be5275e02a1556957a

How TYO Reach's Remote Targets reach servers across clouds (Google IAP, AWS SSM via smux over Session Manager, AWS EC2 Instance Connect Endpoint and Azure Bastion) with hand-rolled native Go tunnels and no cloud SDKs or CLIs. Dashboard-managed targets, identity-gated RDP/SSH/TCP, unified audit, and the Reach relay for everything the clouds can't see.

Each cloud has its own identity-aware way into a server without a public IP, whether Google IAP, AWS SSM and EC2 Instance Connect, or Azure Bastion. Each also has its own CLI, its own login dance and its own quirks. Reach speaks all of them natively from one client, with no cloud SDKs bundled, so a server is just something you click Connect on.

Reach Remote Targets: one client into GCP, AWS and Azure, no cloud SDKs


[Reach RDP](/blog/2026/10/07-reach-rdp-remote-desktop-without-exposing-3389/) got a lot of attention as a way to reach a remote desktop without exposing port 3389. But RDP is really just *one* service riding a more general capability. Reach forwards **any TCP service** on a machine you've shared to a local port on the machine you're sitting at, and once you see it that way, the desktop is only the most visible example.

The question that usually comes after "how do I remote into that PC?" is "...and how do I get to the *database* on it? The file share? The admin page for the NAS? The licence server the accounting software phones home to?" The honest answer with most tools is: open another port on the router, or stand up a VPN and hand over the whole network. Reach's answer is the same as it is for RDP: forward the one service, over an identity-gated path, with nothing exposed.

## What a forward actually is

A forward in Reach is three things: a **remote host**, a **remote port**, and a **local port** that Reach opens on `127.0.0.1` for you. You add it against a machine that has turned on "Share this PC," and Reach stands up a listener on your loopback, say `localhost:15432`. Anything you point at that local port is carried, byte for byte, to `host:5432` on the far machine.

That's the whole model. Your Postgres client connects to `localhost:15432`; as far as it's concerned the database is running on your own machine. `psql`, DBeaver, a JDBC string, `smbclient`, a browser pointed at a router's web UI: none of them know or care that the bytes are travelling through a tunnel to a box behind NAT in another state.

Reach knows a couple of protocols well enough to do the launching for you: pick an **RDP** forward and it writes the `.rdp` and opens mstsc; pick an **SSH** forward and it opens a terminal at the local port. Everything else is a plain TCP forward with a **"copy `localhost:port`"** button. You paste that into whatever client the service needs. The protocol is yours; Reach just moves the bytes.

## RDP or a bare forward? Same door, two ways through

Worth being explicit, because the question comes up the moment you've read the RDP piece: Reach RDP *is* a TCP forward, of port 3389, with a generated `.rdp` written and mstsc launched at it. "Share this PC" is the one mechanism; the full desktop and a bare forward are two things you do with it. The only real choice is how much of the machine you want.

- **The full desktop (RDP).** You get the whole graphical machine: every app, the GUI, the screen. Reach for it when you need to *operate the machine*: run a Windows app, click around a GUI tool, do something there's no client or command line for. The costs: it needs a desktop-capable host (Windows **Pro/Enterprise**; Home can't host RDP), it's heavier on the link because it's carrying a rendered screen, and it takes over the interactive session.
- **A single service (a forward).** You get one port (the database, the share, the admin page) and drive it with your *own* local client. Reach for it when you only need the one thing: it's lighter, it works against Linux boxes, NASes and appliances that have **no "desktop" at all**, you can run several in parallel, and it doesn't tie up anyone's screen. The cost is the mirror image: it's that one service, not a view of the machine, so if what you need is to *see and drive the desktop*, that's RDP's job.

Rule of thumb: **need to see the screen → RDP; need to reach a service → a forward.** Often you want both to the same box, and Reach runs them side by side: an RDP forward and a database forward to the same server are just two entries in the list.

## The substrate is the same one RDP uses

Because a forward is just a tunnelled TCP stream, it inherits everything the RDP path already does:

- **Nothing exposed, nothing forwarded.** The far machine makes an **outbound** control connection to Reach and waits. There's no inbound firewall rule, no public port, no static IP. Your connection is matched to the machine by **identity**, not by an address anyone can scan.
- **P2P when it can, relay when it can't.** If your device and the target are on the **same subnet**, the forward goes **peer-to-peer** and the gateway never sees the bytes. Otherwise it rides the gateway relay. Same decision, same code, as every other Reach connection.
- **Tuned for interactive traffic.** `TCP_NODELAY` on the relay sockets and immediate flushing, so a database session or an SSH shell doesn't feel like it's wading through treacle; the thing that makes a naive tunnel miserable is buffering, and we don't.
- **Scoped sharing.** A shared machine can advertise more than one service, and you grant a specific forward to a specific person. A contractor can get the one port they need and nothing else on the box.

## What you'd actually use it for

The list is basically "anything that listens on a TCP port":

- A **database** (Postgres, MySQL, SQL Server) reached by your normal client, without the database ever being open to the internet (which is how a depressing number of them get ransomwared).
- A **file share** (SMB/445) on the office NAS or a server, mounted from home.
- The **web admin panel** of something that should never face the internet: a NAS, a router, a managed switch, a printer, a Proxmox or Home Assistant box, a UniFi controller.
- A **licence server** or an internal **API** that a desktop app or a dev environment needs to reach.
- **Git over SSH**, or any other SSH-based workflow, to a box with no public SSH port.

## The honest limits

- **It's TCP.** Forwards carry TCP streams. Real-time **UDP** apps (game servers, some VoIP, anything latency-sensitive over datagrams) are a different path; that's what [Reach's adaptive UDP relay](/blog/2026/10/06-reach-udp-adaptive-relay/) is for.
- **Reach carries bytes; it doesn't replace the service's own auth.** A forwarded database still wants its own username and password; a forwarded admin panel still wants its login. Reach gates *who can open the tunnel*; the service gates *what they can do once inside*. That's the right split: defence in depth, not a single gate.
- **It's for machines you own or manage.** The far end has to run "Share this PC" and advertise the service. This is for your fleet, your servers, your team, not for poking at a port on a stranger's network.

The headline is the same one that mattered for RDP, just generalised: you can reach **any service** on any of your machines, from anywhere, with the client you already use, and leave **nothing** listening on the public internet.

*TCP forwards are part of TYO Reach. Already a Reach user? Add one from the tray under "Forwards." New to Reach? [Start here](https://reach.tyo.com.au), or go straight to the [download](https://reach.tyo.com.au/download).*


a6f939cd12c7023dd01015b6fa9a17326151f5da1a79f1411d076fb2ce574f0f

How TYO Reach forwards an arbitrary TCP service (not just RDP) over an identity-gated tunnel, using a local 127.0.0.1 listener bound to a remote host:port on a machine you've shared, P2P-or-relay transport, nothing exposed and nothing forwarded on the router. Reach a database, SMB share, NAS/router/Proxmox web UI, licence server or internal API with the client you already use.

Reach RDP is really one case of a general capability, since Reach forwards any TCP service on a machine you've shared to a local port on yours, so you point your normal client at it. Databases, file shares, admin panels, a licence server, an internal API, all reachable and none of them exposed to the internet.

Reach TCP forwards: any service on your machines, with nothing exposed


There are two usual ways to Remote Desktop into a machine that isn't on your LAN, and both are bad in their own way.

The first is to **forward port 3389** on the router and connect to the public IP. It works, and it's also how a huge share of ransomware gets in; an exposed RDP port is a doormat that every scanner on the internet is already knocking on. The second is to **stand up a VPN** first, which is more work, more to maintain, and usually gives the remote device far more of your network than "I just want to reach that one PC."

Reach RDP is a third way: your **existing** Remote Desktop client connects to the remote machine over an **identity-gated tunnel**, with **nothing exposed** and **nothing forwarded**.

## What it looks like

The remote machine turns on "Share this PC," which advertises its RDP service (port 3389) to your TYO ID, or to a teammate you've explicitly shared it with. From the other end you pick that machine and Reach does two things: it stands up a **local forward** (a listener on `127.0.0.1`) and launches your normal RDP client at it. To mstsc / Microsoft Remote Desktop / Remmina, it looks exactly like connecting to a machine on your own desk. The bytes, meanwhile, are travelling through Reach's tunnel to a box that could be behind NAT, behind CGNAT, or in another country entirely.

No inbound firewall rule. No public 3389. No static IP. The remote machine makes an **outbound** control connection to Reach and waits; your connection is matched to it by **identity**, not by address.

## How the bytes travel

Same substrate as the rest of Reach. If your device and the target are on the **same subnet**, the connection goes **peer-to-peer, directly**, and the gateway never sees your pixels. Otherwise it rides the **gateway relay**. Either way the RDP stream is tunnelled raw, with a couple of deliberate tunings (`TCP_NODELAY` and interactive PDUs flushed immediately) because the thing that makes tunnelled RDP feel awful is buffering keystrokes and mouse movement, and we don't.

## The security posture, and the sharp edges we filed down

RDP is fiddly, and getting it to tunnel *cleanly* took solving some genuinely annoying failure modes. A few worth naming, because they're the difference between "works" and "works reliably":

- **NLA stays on.** The tunnel doesn't weaken authentication: CredSSP / Network Level Authentication is preserved (`authentication level:i:2`). Reach moves bytes; it doesn't stand between you and the server's auth.
- **A forced, fresh credential prompt.** Because every Reach target shares `127.0.0.1` on your machine, mstsc would happily reuse a credential it cached against that address from a *different* box: connect to a domain-joined machine, then a workgroup one, and it tries Kerberos against a KDC it can't reach and dies before you even see a prompt (`0x80090311`). Reach's generated `.rdp` forces the prompt so you enter *that* machine's own credentials.
- **An old-server quirk (`HYBRID_EX`).** Some older RDP servers reset the connection if the client advertises `PROTOCOL_HYBRID_EX`; Reach can strip it from the X.224 request for exactly those hosts (off by default, because modern Windows needs it kept).
- **Secure mode.** For locked-down access you can strip the clipboard, drive and USB redirection virtual channels, so a session is view-and-control only with no data bridge back to the host.

## Multi-monitor, and other client features

Because Reach tunnels the raw RDP stream, **multi-monitor works out of the box**. Reach's generated `.rdp` now sets `use multiple monitors:i:1`, so a full-screen session spans all your displays as if the box were on your desk; it's a no-op on a single monitor, and windowed mode still behaves normally. Same story for other RDP features: they're between your client and the host, and Reach is transparent to them.

## Coming from TeamViewer or AnyDesk?

If you reach your machines with TeamViewer, AnyDesk or Dualmon today, Reach is the same "get to any of my boxes from anywhere" capability with a very different design underneath. Those tools re-encode the remote screen with a proprietary codec and relay it through the vendor's cloud. Reach instead tunnels each OS's **native** remote protocol end-to-end: **RDP** to Windows, **VNC** to a Mac (its built-in Screen Sharing) or Linux, **SSH** for a shell. So you get native fidelity (real multi-monitor, proper keyboard/printer/USB redirection on RDP) rather than a screen video stream, and the whole session is identity-gated with nothing exposed. There's no anonymous nine-digit session code to read out to whoever's on the phone, which is precisely the mechanism those tools get abused through. The trade: Reach reaches machines you **own or have been granted**, not a stranger's PC on a one-off support call.

And RDP isn't the only gear. When you don't need the full graphical desktop, and just want to get back to what you were doing, **Reach Sessions** is the lighter, faster way in: a persistent working session you can detach from and reattach to from any device, picking up exactly where you left off. Full desktop when you need it, a light resumable session when you don't.

## What it isn't

- **It's a transport, not an RDP server.** You still need a remote machine actually running Remote Desktop (a Pro/Enterprise/Server edition; Windows Home doesn't host RDP, and multimon needs a non-Home edition too). That's the *Windows* door specifically; to reach a **Mac** or **Linux** box you use Reach's **VNC/SSH** path instead, so non-Windows targets aren't left out.
- **Secure mode is a trade.** Stripping clipboard/drive/USB is the point when you want it, and an annoyance when you forget it's on; it's per-forward, so you choose.

The headline, though, is the one that matters for anyone who's ever port-forwarded 3389 and then watched the failed-login counter climb: you can have Remote Desktop to any of your machines, from anywhere, using the client you already use, and leave **nothing** listening on the public internet.

*Reach RDP is part of TYO Reach. Already a Reach user? It's in the desktop app under "Share this PC" and Remote Machines. New to Reach? [Start here](https://reach.tyo.com.au), or go straight to the [download](https://reach.tyo.com.au/download).*


882545917a417cb9ab0135129980d145ac59dbdeb529e803ab87a35878e82073

How TYO Reach carries RDP over an identity-gated tunnel to a remote Windows machine with no port-forwarding and no exposed 3389, P2P-or-relay transport, NLA preserved, a forced fresh credential prompt, an optional secure mode that strips clipboard/drive/USB, and transparent multi-monitor passthrough.

Remote Desktop usually means either exposing port 3389 to the internet (the number-one ransomware doormat) or standing up a VPN. Reach RDP does neither. It tunnels your existing Remote Desktop client to the machine over an identity-gated path, so nothing is exposed and nothing is forwarded.

Reach RDP: remote desktop without opening a hole in your network


Ask most proxies to carry a file download and they're flawless. Ask them to carry a voice call, a video meeting, a game, or anything else built on UDP, and things get quiet, sometimes literally. TCP is the happy path for tunnels; UDP is the one that gets dropped, blocked, or silently degraded. That's a problem, because the traffic people most *notice* breaking (calls, Teams, games) is exactly the UDP traffic.

Reach now carries UDP. The interesting part isn't "we added UDP support"; it's **how**, because there is no single UDP transport that is simultaneously fast, firewall-friendly, and hard to block. So instead of picking one, Reach picks the right one **per connection**.

## Three transports, one selector

Under the hood there's a shared UDP layer with three pluggable transports:

- **Direct**: the datagram goes straight out, no tunnel. Right for LAN peers and, by default, for real-time *media* where latency is king.
- **QUIC datagrams**: UDP carried inside a QUIC connection (ALPN `reach-udp`), with a short control stream that carries your key. Fast and modern where the network allows it.
- **UDP-over-WebSocket**: datagrams wrapped in a WebSocket to the gateway. Slower than QUIC, but it looks like ordinary web traffic, which is what you want when the network is hostile.

In front of them sits a small **classifier** and **policy engine**. The classifier buckets each flow into *LAN*, *Media* (STUN/TURN, the common RTP ranges, Teams), or *Other*. The policy then decides: LAN stays direct; media stays direct for latency (or rides WebSocket when you've asked Reach to stay disguised); everything else prefers QUIC, falls back to WebSocket, and only then gives up. Pick the "slow/disguise" connection mode and tunnelled UDP deliberately steps down to the most resilient option. One flow can be direct while another is relayed; the selector is per-connection, not a global switch.

## Where it terminates

Tunnelled UDP has to *exit* somewhere, and that turned out to dictate the architecture. Serverless platforms can't egress raw UDP (we tried, historically, and reverted it). So tunnelled UDP terminates on a small **Go sidecar, `reach-relay`, running on the VM gateways**, which dials the real target itself and relays the datagrams back. Each gateway advertises its UDP capabilities in its `/meta` document, so the client knows whether a given gateway can do `udp-relay`, `udp-quic`, or neither, and routes accordingly. QUIC, because it bypasses the usual web front door, gets its own DNS-only endpoints and a dedicated firewall opening.

On the client side, the desktop gained **SOCKS5 UDP ASSOCIATE**, the standard way for an application to hand UDP to a proxy, wired into the same adaptive selector. So a UDP-capable app points at Reach's local SOCKS proxy and its datagrams flow through whichever transport the policy chose.

## The honest caveats

Per our usual rule, the trade-offs, stated plainly:

- **Desktop today; mobile is coming.** The desktop client ships the full adaptive UDP path. Mobile needs a from-scratch native "protected socket" hook (so the VPN doesn't loop its own traffic), which is a separate build effort in progress, not shipped yet.
- **QUIC does *not* help in China.** The Great Firewall throttles and blocks UDP to foreign IPs, QUIC included. There, the resilient path is UDP-over-WebSocket in disguise mode, which is exactly why the selector exists rather than a single "use QUIC" flag.
- **Rolling out across the fleet.** The UDP sidecar and QUIC are live on most of our gateways, not yet every one. The client degrades gracefully: no UDP transport available on a gateway means it falls back (and, worst case, the app's own direct path), never a hard failure.
- **Metering.** Tunnelled UDP isn't byte-metered yet, a deliberate interim choice while the design settles.

The point of all this machinery is a simple outcome: the real-time traffic that used to be the first casualty of turning on a tunnel now has a way through, and Reach spends its effort choosing the *right* way, connection by connection, instead of forcing one and hoping.

*Reach's adaptive UDP relay is built into the TYO Reach desktop app. Already using Reach? Update to the latest version. New to it? [Start here](https://reach.tyo.com.au), or go straight to the [download](https://reach.tyo.com.au/download).*


53abba03ab54743e04883ad4c24d6b00215f668ba25bda5003634ce8921bd203

How TYO Reach carries UDP with an adaptive relay with three pluggable transports (direct, QUIC datagrams, UDP-over-WebSocket) behind a connection-mode-aware selector, terminating on a Go sidecar on the VM gateways, with desktop SOCKS5 UDP ASSOCIATE.

Most proxies and tunnels carry TCP beautifully and quietly mangle UDP, which is exactly the protocol your voice calls, video, games and real-time tools run on. Reach now carries UDP too, with an adaptive layer that picks the right transport per connection.

Reach UDP: carrying the traffic that tunnels usually drop


Here's a small moment that turns out to be the whole point.

You start a long task in a terminal on your office machine: a build, a data migration, a coding agent chewing through a refactor. Then you step away from that desk. And "away" takes a dozen shapes:

- some days you knock off and pick it up from the couch at **home**;
- some weeks you're barely at a desk at all, because you're **always on the move**, hopping between a desktop at work, a laptop on the road, and a phone or tablet in between;
- you're at a **client's office running a demo**, and you need the thing you left running back at base;
- you're **between meetings** (on the train, in a café, killing time at an airport gate) with ten minutes to check on a job;
- or you simply switched machines mid-thought and don't want to lose your place.

Whichever it is, you open a *different* device. And instead of SSHing in to a **fresh** shell and squinting at log files to reconstruct what happened, the **same session** is right there: the scrollback, the running process, the cursor blinking where you left it. You didn't reconnect to the machine. You picked the session back up.

That's **Reach Sessions**. The insight behind it is that the thing people actually want from remote access isn't connectivity. It's **continuity**. Connectivity ("I can reach that box") is table stakes. Continuity ("my work follows me") is the part that feels like magic the first time. Reach already owns the connectivity substrate; Sessions is the layer that turns a device-bound remote desktop into a session that roams with you.

## What it actually is

A Reach Session is a **persistent terminal that lives on a host**. Any device you own can attach to its live state, full scrollback plus the live stream, and detach again without killing anything. Close the lid, reattach from your phone an hour later, it's all still there.

It rides Reach's existing Zero-Trust transport unchanged, as a new target protocol we call `term` (alongside `rdp`/`vnc`/`ssh`). The gateway doesn't need to understand terminals, being a byte-agnostic relay, so adding Sessions didn't mean re-plumbing the network. It meant adding a small broker on the host and a thin attach client.

## The broker: native PTY, or your existing tmux

On the host, one `Broker` interface has two implementations:

- **Native PTY mux** (the default) gives a real pseudo-terminal per session: `creack/pty` on Linux and macOS, **ConPTY** on Windows. No dependencies, works everywhere.
- **tmux delegate** (Unix, when `tmux` is on the PATH): instead of spawning fresh shells, Reach exposes your **existing tmux sessions**. Run your work in `tmux new -s build`, and that session is now attachable from any of your devices. This is the one that tends to click for people: tmux already gives you persistence *on* the box; Reach gives you persistence *across* boxes.

Starting a host is one command, `reach host`, or a toggle in the desktop tray ("Host sessions on this PC"). From another device you list what's available with `reach sessions` and attach with `reach connect <host> <session>` (or `reach attach`). Detach with `Ctrl-]`; the session keeps running on the host.

## How the bytes get there: P2P first, relay always

When you attach, Reach tries the fast path first: if your device and the host are on the **same subnet**, it connects **directly, peer-to-peer**, and the gateway never touches your data. If they're not (different networks, a laptop on a hotspot, a box in another city) it falls back to the **gateway relay**. Either way the session is addressed by **identity + target**, not by IP: your own devices are discoverable to each other automatically (same owner, no sharing step), and reaching *someone else's* host requires an explicit share.

A detail we recently made seamless: discovery and dialling now work **regardless of which gateway each device happens to be connected to**. Your laptop can be on the closest gateway in one region and the host on another; Reach resolves where the host actually lives and routes the setup there, while your data path stays on the gateway you can actually reach. (That last part matters a lot in networks where only some endpoints are reachable; more on that in a future post about Reach in China.)

## The part we're most interested in: driving agents

Because a Session is just a terminal, you can put *anything* in it, including an AI coding agent. Run Claude Code (or any agent) inside `tmux new -s agent`, and now that agent's session is a first-class Reach target. Attach to it from your laptop, glance at it from a second machine, and, the direction we're building toward, **steer it from your phone**: approve a tool call, nudge it, read where it got stuck, all from a device that was never going to run the agent itself.

That reframes the mental model. The agent doesn't live on "a server you SSH into." It lives in a session, and the session is reachable by identity from wherever you are. The phone becomes a *controller* for long-running work, not a tiny window onto a desktop.

## Honest limits (for now)

We'd rather tell you where the edges are:

- **It's a raw terminal stream**, not a structured API. An external program can drive a Session (the attach client is a plain stdin/stdout bridge, so it pipes fine), but it gets exactly what a human sees, ANSI and all. A clean, framed "run this, give me stdout + exit code" mode for agents is on the roadmap, not shipped.
- **One role per box at a time**: in the current slice a machine is either sharing its desktop *or* hosting sessions, not both simultaneously. Both-at-once is a later enhancement.
- **Mobile is a controller, not yet the full picture**: the phone-steers-your-agent loop is where we're heading; today the solid, shipping surface is the desktop tray and the `reach` CLI.

None of that changes the core, which is already real and in daily use: a terminal that lives on a host, attachable from any device, that picks up exactly where you left it. Start it with `reach host`, attach with `reach connect`, and the next time you move between machines, your work comes with you.

*Reach Sessions is part of TYO Reach. Already a Reach user? It's in the desktop app and the `reach` command line. New to Reach? [Start here](https://reach.tyo.com.au), or go straight to the [download](https://reach.tyo.com.au/download).*


cc83150b335c925cc1cf74ba800a788c70ed61f0d10ab24723b15146d81a2c73

How TYO Reach Sessions works, with a persistent terminal on a host, attachable from any device over the ZTNA transport via a new `term` protocol, backed by a native PTY/ConPTY broker or a tmux delegate, with P2P-or-relay transport and cross-gateway discovery.

Most remote-access tools hand you a connection to a machine. Reach Sessions hands you the live session itself, a terminal that lives on a host and that any of your devices can attach to, detach from, and pick back up exactly where you left it.

Reach Sessions: your terminal follows you, not the other way around


# How to Use AI as Your Personal, Cost-Free Mechanic

Owning a car is expensive enough. Add in poor mechanical diagnostics, and you’re not just paying for parts; you’re paying for guesswork. I’ve personally been through situations where mechanics couldn’t even detect a **blown head gasket**, despite clear symptoms like **loss of compression**, **moisture buildup under the oil cap**. The result? **Wasted money, time, and frustration**, all for zero results. All the money spent on diagnostics could have been used to fix the actual problem in my case for rebuilding the engine.

But now, there's a smarter, cost-free way to approach basic car diagnostics: **AI**. Tools like **ChatGPT**, **Claude**, **Google Gemini**, and other AI assistants can help you think through symptoms, rule out causes, and even generate checklists to discuss with mechanics, **before** you open your wallet.


## My Experience: Misdiagnosed and Wasted

I have an aging 4WD with high mileage. One day, while driving to the Gold Coast, the thermostat suddenly showed the engine temperature skyrocketing. The engine was clearly overheating. When I popped the hood, I saw coolant in the reservoir boiling and overflowing, splashed everywhere. I was also rapidly losing coolant.

I took the car to a mechanic, who couldn’t identify the issue but still charged me a few hundred dollars for general servicing. The problem remained. Hoping for better luck, I brought it to another mechanic, who still couldn't pinpoint the cause. He replaced the radiator cap, thinking it might be the culprit. It wasn’t.

I wasn’t ready to give up on the car, though any sane person probably would have. So I went to the dealership, thinking their team would surely know better. They didn’t. They charged me around two thousand dollars to replace old coolant hoses and the radiator, possibly damaged by a previous mechanic. To be fair, after replacing the radiator, things improved slightly. I wasn’t losing coolant as quickly. But I still had to carry a bottle of coolant everywhere and top off the reservoir regularly.

You might think that was the end of it, but things went from bad to worse. One day, the car suddenly lost power. The engine started shaking violently, and no matter how hard I pressed the accelerator, it wouldn’t respond properly.

Regrettably, I took it back to the dealership. One of their staff went on a test drive with me to feel how underpowered the car had become. Their mechanic inspected it, scratched his head, and said they needed to perform a compression test, a fuel injection test, and other diagnostics, which came at a steep cost. They suspected a fuel injection problem. I paid around another thousand dollars for those tests. The result? A vague diagnosis stating that one of the cylinders wasn’t producing enough power.

They then told me a second-hand engine would cost around $25,000, not including labor. At that point, the car was essentially worthless. I couldn’t even sell it, except maybe to a dealer, and the car wasn’t worth nearly as much as I had already spent on it.

To keep the car, I considered buying a used engine from eBay or a wrecker for much less than the dealership’s quote. But could I trust an unknown engine with no clear history? Later, I learned that engine rebuilding was another option. However, people warned me that rebuilding can be more expensive than replacement and not always worthwhile.

What should I do? Unfortunately, ChatGPT wasn’t available at the time. I did a lot of Googling and research. Eventually, I realized the symptoms pointed to a **blown head gasket**, causing **low compression** and **loss of power**. Coolant had entered the engine, and when the engine ran, **white smoke** came out of the exhaust.

Later, I met a new friend who recommended a trusted mechanic. I took the car to him. He opened the engine cap, inspected the internals, and immediately suspected water in the engine. He told me to come back later for more testing. Eventually, he confirmed the diagnosis and offered to rebuild the engine for a surprisingly reasonable price, less than I had expected. However, there was a wait. I had to book months in advance because the engineer he worked with had a huge backlog. He needed to X-ray the engine block to ensure there were no cracks.

My experience with the car had been anything but smooth. A few months later, I finally got the car back. Even after the rebuild, the engine had misfires. The mechanic asked me to return in a week so he could investigate further. Luckily, the engine itself was fine. He just needed to **reprogram the ECU (car computer)**. After that, the car ran perfectly again.

I was thrilled to have my car back in good condition. But the entire experience taught me a valuable lesson: **correct diagnosis is everything**, and you can’t always rely on mechanics to get it right.

But my story didn’t end there. A year later, I took the car in for a routine service. The mechanic told me everything was generally fine, but some parts needed replacing. He also advised that I take the car to a specialized shop to replace the **steering rack**, which would be cheaper there. I followed his advice and got it done.

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2025/05/using-ai-as-your-personal-cost-free-mechanic/steering-rack.png)

A few days later, I started hearing **a faint noise when turning**, not loud, but definitely noticeable. I didn’t feel good about it and wasn’t sure if I should call the shop again. Then I had an idea: why not ask **ChatGPT**?

I’d been using AI tools since they became popular, for writing, coding, and even image generation, but I’d never used them for **mechanical diagnostics**.

From that point on, I decided to research more deeply and talk to AI systems like ChatGPT to help me understand car symptoms. The responses were surprisingly accurate, detailed, and useful.


## AI Diagnosing Steering Noise After Rack Replacement

### Main Symptom: Screeching Noise

Here was my prompt to ChatGPT:
>My car replaced the steering rack, but started to make screeching noise while turning, is it normal

**ChatGPT**:
No, it is not normal for your car to make a screeching noise while turning after replacing the steering rack. This could indicate one of several issues, such as:

- Low Power Steering Fluid – Air might have entered the system or it wasn't properly refilled and bled after the rack replacement.

- Improperly Installed or Loose Belt – If the power steering uses a belt-driven pump, a loose or worn belt can cause screeching.

- Misaligned Steering Components – If parts weren’t aligned correctly during reassembly, it can lead to abnormal noises.

- Pump Issues – The power steering pump might have been strained or damaged during the rack replacement.

- Dry or Unlubricated Joints – Some steering components may need lubrication and could squeak if dry.

It's best to have the mechanic recheck the installation to avoid further damage. Did the noise start immediately after the replacement, or did it develop gradually?

**Me**:
>Gradually, I think

**ChatGPT**:
Since the screeching noise developed gradually after the steering rack replacement, it's likely related to power steering fluid issues (e.g., low fluid or air trapped in the system) or a loosening belt that drives the power steering pump.

Here’s what you can do:

*. Check the power steering fluid level – Make sure it’s at the proper level and not foamy or discolored (which can indicate air or contamination).

*. Inspect the drive belt – See if it’s worn, loose, or slipping, especially when turning the wheel.

*. Listen closely to where the noise comes from – If it’s near the pump or belt, that narrows it down.

If you're not comfortable checking these yourself, it’s wise to return to the mechanic who did the work and explain the gradual onset of the noise. It may just need a fluid top-up and proper bleeding.

Would you like a checklist you can bring to the mechanic to describe the problem clearly?

**Me**:
>I checked again, actually there were some noises when turning, but I can't say that is screeching

**ChatGPT**:
Since the screeching noise developed gradually after the steering rack replacement, it's likely related to power steering fluid issues (e.g., low fluid or air trapped in the system) or a loosening belt that drives the power steering pump.

Here’s what you can do:

- Check the power steering fluid level – Make sure it’s at the proper level and not foamy or discolored (which can indicate air or contamination).

- Inspect the drive belt – See if it’s worn, loose, or slipping, especially when turning the wheel.

- Listen closely to where the noise comes from – If it’s near the pump or belt, that narrows it down.

If you're not comfortable checking these yourself, it’s wise to return to the mechanic who did the work and explain the gradual onset of the noise. It may just need a fluid top-up and proper bleeding.

Would you like a checklist you can bring to the mechanic to describe the problem clearly?

**Me**:
>a bit like wind blowing

**ChatGPT**:
Thanks—that’s a very helpful description. If the noise sounds like wind blowing when turning, it's likely a power steering-related whine. This often happens due to:

1. Air trapped in the power steering system – Common after replacing the steering rack if the system wasn't properly bled.

2. Low or degraded power steering fluid – Can cause a faint whining or "windy" sound as the pump struggles to circulate it.

3. Power steering pump wear – If the pump was already aging, the new rack could put added strain on it.

**What You Can Do:**
- Check fluid level – Make sure it's between the min and max marks. If it’s low, top it up with the correct type for your car.

- Inspect fluid quality – If it’s foamy or milky, that’s air in the system. A mechanic can bleed it properly.

- Turn the wheel lock-to-lock (fully left to right, a few times) while the engine is running, to help purge air—only if fluid level is good.

If the sound persists after doing this, it’s worth having the shop recheck the bleed and fluid or inspect for a potential issue with the pump.

Would you like help finding the right fluid type or a quick guide on how to check and top up the power steering fluid?


### Another Symptom: "Chick Chick" Sound During Acceleration

Other than the steering noise, I also had a **"chick chick" sound** when accelerating. I asked ChatGPT about it:
>When I accelerate, I can hear some tiny chick chick sound, what do you think that would be

**ChatGPT**:
A faint “chick chick” sound during acceleration could be caused by a few different things, depending on the location and rhythm of the sound. Here are some common possibilities:

1. CV Joint or Axle Issue
If the sound changes with speed and especially when turning or accelerating from a stop, it could be a worn CV joint or axle.

Check if the sound is louder when turning—this would point more directly to a CV joint.

2. Loose Heat Shield or Exhaust Component
A loose metal shield near the exhaust can rattle or tick lightly during acceleration when vibrations increase.

3. Spark Plug or Engine Misfire (less likely if it’s very faint)
Sometimes a tiny ticking sound can be from the ignition system—such as spark plug arcing—but this is usually more noticeable and may come with poor engine performance.

4. Belt or Pulley
A worn serpentine belt or a slightly loose pulley can make clicking/ticking noises, especially under load.

5. Plastic Splash Guard or Trim Contact
Occasionally, plastic underbody panels or fender liners can flap or tick against a moving part if loose.

To help pinpoint it better:

- Is the sound from the engine bay, wheels, or underneath?

- Does it change with RPM, speed, or only when pressing the gas?

Would you like a short checklist you can use while test-driving to help identify where it’s coming from?

### Actions

Based on ChatGPT’s diagnosis, everything seemed to point to the newly replaced steering rack. So I decided to check the power steering fluid level first, and it was low. I topped it up and drove around for a while, making plenty of full lock-to-lock turns. However, the noise didn’t go away. When I checked the fluid level again, I was surprised to see it had dropped once more. I quickly looked under the car and noticed a small puddle of leaking oil. 

I took the car back to the mechanic, who inspected it and found that power steering fluid was pouring out. He did a quick check, tightened a pipe or some component (I’m not entirely sure what it was), and that solved the problem. The noise disappeared, and even the light “chink chink” sound I used to hear during acceleration was gone. 

**ChatGPT was right!!!**


## Final Thoughts

AI doesn’t replace a qualified mechanic, but it **empowers you as a car owner**. It gives you confidence, saves you time, and helps protect your wallet from guesswork.

Next time your car acts up, try this:
1. Describe the issue to ChatGPT or another AI assistant.
2. Read the explanations carefully and follow suggestions.
3. Check what you can safely yourself.
4. Go to a mechanic **with clarity and confidence**.

You might be surprised how far AI can take you, **before you ever lift the hood or reach for your credit card**.


078afc664360c91bae2806110f8d1636259275b9badf520cdc80c477f7b200a7

In this article, we explore how AI can help you diagnose car issues and save money on mechanic fees. Learn how to use AI tools like ChatGPT and Claude to troubleshoot car problems before visiting a mechanic.

In this article, we explore how AI can help you diagnose car issues and save money on mechanic fees.

Using AI as Your Personal, Cost-Free Mechanic


# A Simple Guide to Installing a Reverse Camera on Your Car

## Introduction
It doesn't matter what type of car you drive, and what sort of head unit you have, it all come down to a same principle when it comes to installing a reverse camera. This guide will give you some ideas how to install a reverse camera on your car, including a wiring diagram. Also, we will focus on connecting the camera to the head unit, which is the most common setup.

## Basic Wiring

The goals of the wiring are to:
- When the reverse gear is engaged, the camera is powered on
- We can see the camera feed on the head unit when switching it on manually

The entire wiring setup can be broken down into three main components:
- Connect the camera to the reverse light 
- Connect the camera to the head unit
- Connect the camera to a switch

### Head Unit
From the head unit, the most important wires are:
- the RCA cable. This is a yellow plug that is usually located at the back of the head unit.
- the reverse trigger wire. This is a wire that is usually connected to the reverse light. When the reverse light is on, the wire is powered on. This is the wire that tells the head unit to switch to the camera feed.
- the +12V wire. This is the power wire that powers the camera when the switch is on.

### Reverse Camera
The reverse camera usually has three wires:
- the video wire. This is the wire that carries the video feed from the camera to the head unit via the RCA cable.
- the red (positive) wire. 
- the black wire, which is the ground.

You can easily identify those wires by referring to the camera's manual.

### Reverse Light
All cars have reverse light, though some cars have only one reverse light. Anyway this is the light that turns on when you put the car in reverse. This is the light that we will tap into to power the camera when the reverse gear is engaged if the car doesn't provide a reverse power wire already. 

### Connecting Everything Together

#### Wiring Diagram

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/reverse_camera_wiring_diagram.svg)

You may change the wiring a bit based on your own needs or circumstances. It may worthy of mentioning that it is a very important to connect (solder) a diode between the +12v power source and the reverse light power source. When we switch on the power source manually but we shouldn't power the reverse light as well. This is to prevent the reverse light from turning on when the switch is on.

## Camera Positioning
Generally, you find a center point on the rear of the car, and then measure the distance to the left and right of the center point. This will give you the exact position where the camera should be mounted. But I don't think it has to be in the exact center as the camera mainly provide a view of the rear of the car. It would be easier though to have it in the center as it will give you a symmetrical view particularly when you park the car in reverse.

Depending on the car model, some cars have a camera hole already, some don't. If your car doesn't have a camera hole, you will need to drill a hole to mount the camera.

## Tools and Materials Needed
- Auto electrical wire (4~5m) if you have to tap into the reverse light
- Soldering iron if you have to tap into the reverse light
- Heat shrink tubing (optional)
- Electrical tape
- Wire stripper
- Drill and drill bits
- Electrical wire crimper
- Electrical wire connectors (terminals)
- Car auto fuse (if you accidentally blow a fuse during the installation)
- Electrical wire voltage tester (in case fuse gets blown)

## Troubleshooting Tips
- If the camera doesn't turn on when the reverse gear is engaged, check the reverse trigger wire connection.
- If the camera feed doesn't show up on the head unit when the reverse gear is engaged, check the RCA cable connection.
- If the camera doesn't turn on when the switch is on, check the +12V wire connection.
- If everything is fine, except that your indicator light doesn't work, and reverse light is not on when the reverse gear is engaged, check the auto fuse. Yes, that happened to me.

## References
You can find some videos how connect two wires together, how to use a soldering iron, how to use a wire stripper, how to use a drill, how to use a wire crimper, how to use a voltage tester, etc. on YouTube. 
### Wiring videos
- [How to connect two wires together](https://www.youtube.com/results?search_query=How+to+connect+two+wires+together)
- [How to use a soldering iron](https://www.youtube.com/results?search_query=How+to+use+a+soldering+iron)
- [How to use a wire stripper](https://www.youtube.com/results?search_query=How+to+use+a+wire+stripper)
- [How to use a drill](https://www.youtube.com/results?search_query=How+to+use+a+drill)
- [How to use a wire crimper](https://www.youtube.com/results?search_query=How+to+use+a+wire+crimper)
- [How to use a voltage tester](https://www.youtube.com/results?search_query=How+to+use+a+voltage+tester)

### Tapping into the reverse light
I strongly recommend you to watch a video recorded by Super Cheap Auto, which shows you how to tap into the reverse light. This video is very helpful, and it will give you a good idea how to tap into the reverse light.

Please find this video from this link: [How to Install A Reverse Camera - Super DIYs](https://www.youtube.com/watch?v=YHW-EZHW0Ec), the particular part of tapping into the reverse light starts from 1:10.

## Conclusion
The installation of a reverse camera is not difficult, but it does require some basic knowledge of car wiring. Once you understand the principle and ideas how components connect to each other from the wiring diagram, everything will be clear.

## Credits
Photo by <a href="https://unsplash.com/@rebusas?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Evaldas Grižas</a> on <a href="https://unsplash.com/photos/a-couple-of-lights-that-are-in-the-dark-FQ3ohyLqVhM?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Unsplash</a>
  

## Contact

I installed a reverse camera on my Land Cruiser Prado (120 series), and everything works beautifully. I hope this guide will help you to install one on your car.

For suggestions, errors or any others. 

I can be reach via:

- X (formally twitter): [Eric Tang](https://x.com/_e_tang)
- email: [eric@tyo.com.au](mailto:eric@tyo.com.au) 

4bb358dc80c9bab0fdb8e12fe72a734e7fc7f6ad2b9964bd78c25dc955f212f0

A tutorial shows you how to install a reverse camera on your car including a wiring diagram

Using a wiring diagram to show you how to install a reverse camera on your car

Tag: Technology