# Codeusse — Full Content
> Mobile Agentic IDE & Persistent Terminal for remote AI workflows.
## Product Overview
Codeusse connects to your machine over standard SSH and keeps your sessions alive with tmux.
Run Claude Code, OpenCode, Aider, and Codex on your machine — full terminal UI, native performance.
Features a code editor, shell client, file manager, and agent tools — all on your phone.
No cloud lock-in, no sign-up required. Your SSH keys stay on your device.
---
# Why Install Yet Another Remote Shell When SSH Is Already on Your Machine?
> SSH comes pre-installed on every Linux distribution and macOS. Here's why that matters — and how Codeusse builds directly on what you already have.
Mobile SSH apps have multiplied over the last few years. Some, like Mosh-based clients (including Moshi), promise a better terminal experience over flaky connections. Others layer on proprietary protocols, cloud relays, or custom daemons that need installing on your host. But there is a simpler starting point that often gets overlooked: **SSH is already on your machine.** Every major Linux distribution ships with OpenSSH. macOS has shipped with it for over a decade. You do not need to install anything on the server side to get started.
This post looks at why that pre-installed foundation matters, how tools like Moshi diverge from it, and why Codeusse was built to embrace it.
## The silent advantage of built-in SSH
Open a terminal on any Linux box or Mac. Type `ssh`. It is there. No package manager, no Homebrew, no compilation required. The protocol that secures remote access for millions of servers, cloud instances, and development machines is already baked into your operating system.
That means:
- **Zero server-side setup.** If you have enabled the SSH server (`sshd`) on your host, you are ready. No extra daemons, no additional ports to open, no new attack surfaces.
- **Universal key management.** Your `~/.ssh/authorized_keys`, `ssh-agent`, and hardware security keys all work as expected. Nothing to duplicate or migrate.
- **Proven security.** OpenSSH has been battle-tested for over two decades. It is audited, patched, and trusted by every major OS vendor.
- **Ecosystem compatibility.** Git, rsync, scp, VS Code Remote, Ansible — the entire DevOps toolchain speaks SSH natively.
## Moshi and Mosh: a different path
[Moshi](https://apps.apple.com/us/app/moshi-mosh-client/id1256618614) is a well-made Mosh client for iOS. [Mosh](https://mosh.org/) (Mobile Shell) was designed to improve SSH on high-latency or intermittent connections by using UDP and local echo. It works by installing a `mosh-server` binary on your remote host, which sits alongside (or replaces) your SSH session.
Mosh solves a real problem — typing lag and dropped connections over cellular — but it comes with trade-offs that matter for a development workflow:
### What Mosh adds
| Capability | How Mosh handles it |
|---|---|
| Roaming and reconnection | UDP-based session that survives IP changes |
| Local echo | Types appear instantly before the server confirms |
| Predictive rendering | Smart reduction of terminal redraw traffic |
### What Mosh gives up
| Limitation | Impact on development |
|---|---|
| No scrollback | Once output scrolls off screen, it is gone. No `tmux` scrollback, no terminal buffer. |
| No agent forwarding | Your SSH agent (`ssh -A`) does not work through Mosh. No key forwarding for Git operations inside the session. |
| No port forwarding | `-L` and `-R` tunnels are unavailable. No tunneling a database or dev server through your connection. |
| No `sshd` integration | Mosh bypasses the SSH server after authentication. Audit logging, `ForceCommand`, and server-side `sshd_config` policies do not apply. |
| Server-side binary required | You must install `mosh-server` on every host you connect to. Not available by default on any OS. |
| Extra firewall ports | Mosh uses a range of UDP ports (60000–61000 by default). Each connection needs a firewall opening. |
For SSH administration — restarting a service, checking logs — Mosh can be a nice upgrade. But for a development environment where you run AI coding agents, use `tmux` for session persistence, forward ports, and audit access? The trade-offs start to hurt.
## Why Codeusse stays on standard SSH
Codeusse connects over vanilla SSH. No UDP layer, no custom protocol, no server-side binary you need to install. The same `sshd` that ships with Ubuntu, Debian, Fedora, Arch, and macOS is the only requirement.
### What you get with standard SSH in Codeusse
| Feature | Moshi (Mosh) | Codeusse |
|---|---|---|
| Server-side requirements | Install `mosh-server` | Enable SSH (already installed) |
| Protocol | UDP + SSH bootstrap | Standard SSH (TCP) |
| Session persistence | No (stateless) | Automatic tmux sessions |
| Scrollback | None | Full tmux scrollback |
| AI coding agents | Not supported | First-class support |
| Code editor | No | Built-in touch editor |
| File manager | No | Full file browser |
| Agent forwarding | No | Yes |
| Port forwarding | No | Yes (`-L` / `-R`) |
| Firewall ports | 1 SSH + UDP range | 1 SSH port |
| Audit logging via sshd | No (bypasses sshd) | Yes |
| Works on a Pi, VPS, or old laptop | Needs `mosh-server` | Works out of the box |
### tmux is the persistence story
Mosh sells itself on reconnecting after network changes. That is genuinely useful. But Codeusse achieves the same goal — and more — through `tmux`, running over standard SSH. If your network drops, your `tmux` session keeps running on the server. When you reconnect, you attach right back where you left off. No UDP tricks, no port ranges, no extra server binary. Just `tmux`, which is available on practically every server and trivial to install if missing.
The difference is philosophical. Mosh tries to solve the flaky-network problem at the **transport layer**. Codeusse solves it at the **session layer**. The transport layer approach requires everyone to install new software. The session layer approach works with what already exists.
### Security stays where it belongs
Because Codeusse uses standard SSH, every connection inherits your host's existing security posture. Your `sshd_config` rules apply. Your `AllowUsers` and `AllowGroups` restrictions apply. Your audit logs capture every authentication. Your fail2ban or crowdsec rules fire as expected.
Mosh authenticates through SSH initially, then pivots to a UDP channel that bypasses `sshd` entirely. For teams or organisations that rely on server-side access controls, that gap is significant.
## When should you use Mosh?
Mosh has its place. If you are SSH-ing into a server over a spotty 4G connection to check on a long-running process, and you do not need scrollback, agent forwarding, or any of the SSH ecosystem features — Mosh is excellent at what it does. Moshi provides a polished iOS client for that workflow.
But if you are:
- Running AI coding agents like Claude Code, Aider, or OpenCode on a remote machine
- Maintaining long-lived `tmux` sessions for development
- Pushing and pulling from Git repositories via SSH
- Tunneling databases or dev servers through your connection
- Writing, reviewing, and editing code from your phone
... then the standard SSH stack with `tmux` gives you everything that Mosh can, plus the full ecosystem that Mosh cannot.
## Getting started
The best part is how little you need to do. On your Linux or macOS host, make sure the SSH server is running:
- **macOS:** `System Settings` → `General` → `Sharing` → enable `Remote Login` ([full guide](/blog/enable-ssh-server-on-macos))
- **Ubuntu/Debian:** `sudo systemctl enable --now ssh`
- **Fedora/RHEL:** `sudo systemctl enable --now sshd`
- **Raspberry Pi:** Use the Raspberry Pi Imager to pre-configure SSH ([full guide](/blog/setup-raspberry-pi-ssh-codeusse))
That is it. No extra packages. No UDP port ranges. No custom daemons. Just `ssh`, which is already there.
Install Codeusse from the [App Store](https://apps.apple.com/us/app/codeusse-ssh-client/id6757916854), add your host, and start coding. Your agents get a persistent `tmux` session, a touch-first code editor, and a file manager — all over the SSH protocol your machine has understood since the day you installed it.
---
# Transitioning from Termius and Blink Shell to Codeusse for Remote AI Agents
> A comparison of mobile SSH clients — Termius, Blink Shell, and Codeusse — and why AI coding agents need a different kind of mobile terminal.
If you code on the go, you have probably tried one of the big-name mobile SSH clients. Termius and Blink Shell each solve part of the remote access problem. But if your workflow now includes AI coding agents — Claude Code, Aider, OpenCode, or Codex — the requirements change. This post compares what each tool offers and why Codeusse was built specifically for the agent-first developer.
## The landscape at a glance
| Feature | Termius | Blink Shell | Codeusse |
|---|---|---|---|
| Platform | iOS, Android, Desktop | iOS | iOS (iPad + iPhone) |
| SSH terminal | Yes | Yes | Yes |
| AI agent coding | No | No | Yes |
| Built-in code editor | No | No | Yes |
| File manager | Snippets only | No | Yes |
| tmux session persistence | Manual | Manual | Automatic |
| Agent tool integration | No | No | Yes |
| No cloud relay required | Depends on plan | Yes | Yes |
## Termius: the cross-platform powerhouse
[Termius](https://termius.com/) is the most widely known mobile SSH client, and for good reason. It syncs your connections across devices, supports key-based authentication, and has a polished UI on every platform. The snippet system is genuinely useful for saving common commands, and the SFTP client covers basic file transfers.
**Where Termius falls short for agents:** Termius treats SSH as a pipe for a human typing commands. That works for manual administration — restart a service, tail a log, run a one-off script. But AI coding agents need a *persistent environment*. They expect long-running sessions, working directories that survive disconnects, and a terminal that the agent can drive through structured tool calls. Termius has no concept of an agent tool protocol, no tmux-first session management, and no code editor for reviewing or tweaking agent output on the go.
## Blink Shell: the power user's terminal
[Blink Shell](https://blink.sh/) earned its reputation by building a fast, native terminal for iOS. If you want a raw Unix shell on your iPad that feels like a desktop terminal, Blink is excellent. Its keyboard support and scripting capabilities appeal to developers who want maximum control.
**Where Blink Shell falls short for agents:** Blink gives you a terminal — period. There is no file browser, no code editor, and no awareness of AI coding agents. You can certainly SSH into a machine and run `claude` or `aider` inside a tmux session, but Blink provides zero integration around that workflow. No tool pipeline, no context management, no agent-specific UI. It is a fantastic terminal emulator, but an agentic IDE it is not.
## Why Codeusse was built differently
Codeusse does not compete with these tools on being a generic SSH terminal. It assumes you already have a terminal, and builds the rest of the agent coding stack around it.
### Agent-first design
Codeusse is aware of coding agents as a first-class concept. It connects over standard SSH, attaches to a dedicated tmux session, and lets agents like Claude Code and OpenCode run on your machine with full terminal UI and native performance. The agent runs where your code lives — not in a sandbox, not on a cloud relay.
### Built-in tools that agents need
- **Code Editor:** Touch-first editing with syntax awareness and fast file switching. When an agent proposes a diff, you can review and tweak it on your phone before applying.
- **Shell:** A genuine SSH terminal that runs the same commands you would on a laptop. The agent surfaces proposed shell steps for your approval.
- **File Manager:** Browse your project as files and folders. Open, rename, organize, or share without leaving the app. Bookmark directories for quick access.
- **Agent Tools:** The refactor agent pulls in external context — documentation, APIs, known patterns — so suggestions match real-world constraints.
### tmux for persistence, not as an afterthought
Termius and Blink Shell both *support* tmux — if you set it up yourself, remember to attach to the right session, and hope nothing goes wrong between connections. Codeusse makes tmux the default. It creates dedicated `codeusse-` prefixed sessions, uploads a custom configuration, and falls back to a plain shell only when tmux is genuinely unavailable. Detach, reattach, lose your network — your session is exactly where you left it.
### Security without compromise
Every connection is encrypted over industry-standard SSH. Your private keys stay on your device — no credentials are stored on our servers. You control which hosts you connect to and can revoke access at any time. There is no mandatory cloud relay, no third-party proxy inspecting your traffic. Just SSH, the way it was designed.
## Making the switch
If you are currently using Termius or Blink Shell for general SSH access, you do not have to abandon them. They remain excellent at what they do. The question is whether your workflow has grown to include AI coding agents — and if it has, Codeusse fills the gap those tools were never designed to address.
Install Codeusse from the [App Store](https://apps.apple.com/us/app/codeusse-ssh-client/id6757916854), enable SSH on your host (check our guides for [macOS](/blog/enable-ssh-server-on-macos) and [Raspberry Pi](/blog/setup-raspberry-pi-ssh-codeusse)), and give your agents a terminal that was built for them.
---
# Introducing Codeusse Connect: Secure Tunneling for Mobile Access
> Codeusse Connect bridges your mobile device and local machine over SSH, so you can code from anywhere while your dev environment stays right where it belongs.
Codeusse lets you code from your phone. But your projects, tools, and terminals live on a real machine — your laptop, a desktop, or a server back home. Codeusse Connect is the secure bridge between them.
Under the hood, Codeusse Connect is an SSH tunneling service. It uses [sish](https://docs.ssi.sh/), an open-source SSH-tier reverse tunneling server, to route traffic from the Codeusse mobile app back to your machine — all over an encrypted SSH connection. No port forwarding on your router, no third-party proxies inspecting your traffic. Just SSH.
## How It Works
When you run `npx codeusse-connect` on your machine, three things happen:
1. The CLI opens an SSH connection to `connect.codeusse.com:40074`, Codeusse's sish server.
2. It requests a **reverse port forward** — sish allocates a public-facing port from a small, predefined range, and starts forwarding any traffic that hits that port back through the SSH tunnel.
3. The CLI displays a **QR code** containing the SSH address (e.g., `ssh://connect.codeusse.com:40076`). You scan it with the Codeusse app, and you're connected.
The architecture is split into a backend and a CLI:
| Component | What It Does |
|---|---|
| **Backend** | Docker Compose deployment of the sish server, plus a key generation script. A single `antoniomika/sish:latest` container runs in host network mode, listening for SSH tunnel requests on port `40074`. |
| **CLI** (`cli/`) | The `codeusse-connect` npm package. Uses `ssh2` under the hood to connect to sish, request a reverse forward, and pipe incoming TCP connections to your local SSH daemon on `127.0.0.1:22`. |
## The sish Setup
sish is configured for **SSH-only tunneling**. TCP-level forwarding is explicitly disabled, which means all traffic flows through the SSH protocol layer. No raw TCP ports are opened directly — every connection is negotiated inside an SSH channel. The server uses an ED25519 host key, and the client never sees or stores credentials for the sish server itself.
The port range is deliberately small. This isn't a public ngrok-style gateway designed for thousands of concurrent users. It's a focused service for Codeusse users who need a short-lived tunnel to their own machine.
## Security: The Tunnel Is Not the Gate
This is the part that matters most.
A reverse SSH tunnel is a **pipe**, not a passport. When sish forwards a connection through the tunnel, it doesn't authenticate the inbound client — it just routes the bytes. The real authentication happens at the **end of the pipe**: your local SSH server (`sshd`).
Here's the full security flow:
graph LR
A["CLI
npx codeusse-connect"] -->|"opens reverse SSH tunnel"| B[sish Server]
B -->|"allocates public port"| C[Mobile Device
Codeusse App]
C -->|"SSH to tunneled port"| B
B -->|"forwards to 127.0.0.1:22"| D[Local SSH Daemon
sshd]
D -->|"validates SSH key"| E[Authenticated Session]
style A fill:#fff,stroke:#ee5a24,color:#333
style B fill:#fff,stroke:#ff6b6b,color:#333
style C fill:#fff,stroke:#ee5a24,color:#333
style D fill:#fff,stroke:#ff6b6b,color:#333
style E fill:#ee5a2415,stroke:#27ae60,color:#27ae60
graph TD
A["CLI
npx codeusse-connect"] -->|"opens reverse SSH tunnel"| B[sish Server]
B -->|"allocates public port"| C[Mobile Device
Codeusse App]
C -->|"SSH to tunneled port"| B
B -->|"forwards to 127.0.0.1:22"| D[Local SSH Daemon
sshd]
D -->|"validates SSH key"| E[Authenticated Session]
style A fill:#fff,stroke:#ee5a24,color:#333
style B fill:#fff,stroke:#ff6b6b,color:#333
style C fill:#fff,stroke:#ee5a24,color:#333
style D fill:#fff,stroke:#ff6b6b,color:#333
style E fill:#ee5a2415,stroke:#27ae60,color:#27ae60
Even if someone discovers your tunnel address — even if they connect through `ssh://connect.codeusse.com:40076` — they land on your local SSH server, which demands the same credentials as any SSH login to your machine. No valid key, no access. The tunnel itself grants **nothing**.
This is why the CLI banner says "Only pre-setup devices can connect." The "pre-setup" is your local SSH configuration — keys you've already authorized, users you've already created. Codeusse Connect doesn't introduce a new authentication surface. It inherits the one you already trust.
Additionally, sish's `authorized/` keys directory infrastructure is in place for future enforcement at the server layer, should that become desirable. For now, the design consciously pushes authentication to the edge — your machine — where it belongs.
## Getting Started
If you want to try Codeusse Connect, make sure your local machine has an SSH server running (check with `sudo systemctl status ssh` on Linux or follow our [macOS SSH setup guide](/blog/enable-ssh-server-on-macos)). Then:
```bash
npx codeusse-connect
```
That's it. The CLI connects to `connect.codeusse.com:40074` by default, sets up the tunnel to port `22`, and shows you a QR code. Scan it from the Codeusse app, and you're in.
You can customize the connection if you're running your own sish instance or forwarding a different port:
| Option | Environment Variable | Default |
|---|---|---|
| `--host ` | `CODEUSSE_HOST` | `connect.codeusse.com` |
| `--port ` | `CODEUSSE_PORT` | `40074` |
| `--local-port ` | `CODEUSSE_LOCAL_PORT` | `22` |
| `--username ` | `CODEUSSE_USERNAME` | `codeusse` |
Press `Ctrl+C` to close the tunnel when you're done.
## Under the Hood
The CLI is built in TypeScript and published as an npm package. The core tunnel logic uses the `ssh2` library under the hood, requesting a `forwardIn` (the programmatic equivalent of `ssh -R`) to pipe bidirectional TCP streams between the remote channel and your local port. Configuration pulls from both CLI flags and environment variables. QR codes are rendered in the terminal via `qrcode-terminal`.
On the server side, sish runs in a single Docker container with host networking. The entire backend deployment — config, compose file, and key generation — fits in about 40 lines of code across three files. No databases, no web dashboards, no session state. Just SSH.
---
# The Ideal Host Setup for Codeusse 2
> What to configure on your SSH host to get the most out of Codeusse 2: tmux for session persistence, key-based authentication, and why it matters on mobile networks.
Codeusse 2 brings **tmux session persistence** to every SSH connection. That changes what an ideal host looks like. A few deliberate choices on the server side can mean the difference between a session that survives a subway ride and one that drops the moment you lose signal.
Here is the short version of what to optimize, and why each piece matters.
## 1. Install tmux — it is now essential
Codeusse 2 expects **tmux** on the host. When it is available, the app creates and attaches to a dedicated `codeusse-main` session that lives on the server even when your phone disconnects. When it is not available, Codeusse falls back to a **plain SSH session**.
That fallback works, but it is **flaky on mobile networks**. A plain shell dies with the TCP connection. On a phone that switches between Wi-Fi and cellular, rides an elevator, or simply locks the screen, that means your working directory, running processes, and scrollback vanish. tmux keeps all of that alive server-side, so reconnecting is instant and lossless.
Most Linux distributions and BSDs ship tmux in their base repositories. macOS users can install it through [Homebrew](https://brew.sh):
```bash
brew install tmux
```
For other systems, see the full [tmux installation guide](/blog/tmux-session-persistence-codeusse).
## 2. Prefer SSH key authentication
**Private-key authentication** is the recommended default for any host you reach over the internet or an untrusted network. It eliminates password prompts, resists brute-force attacks, and pairs cleanly with SSH agents.
You do not need an elaborate setup. A standard Ed25519 key is enough:
```bash
ssh-keygen -t ed25519 -C "codeusse"
```
Copy the public key to your host with:
```bash
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host
```
Then store the private key in Codeusse and connect without typing a password.
### When password auth is fine
Password authentication is **perfectly acceptable** when **both** of these are true:
- You connect only over a **local network** (e.g., home Wi-Fi, a lab LAN).
- Or you tunnel through a **trusted VPN** you control.
In those cases the attack surface is small, and the convenience of skipping key setup may outweigh the risk. Just remember that passwords sent over SSH are still encrypted in transit; the main concern is brute-force exposure on internet-facing hosts.
## 3. Summary checklist
| Concern | Recommendation |
|---|---|
| Session survival | Install **tmux** so Codeusse can persist `codeusse-main` |
| Reconnection quality | Avoid plain SSH fallback on mobile networks |
| Authentication | Use **private keys** for internet-facing hosts |
| Trusted local/VPN | Password auth is fine if the network is controlled |
Take ten minutes to install tmux and copy an SSH key to your host, and Codeusse 2 becomes meaningfully more reliable — especially when you are coding on the move.
---
Have questions about tuning your host? Drop by our [Reddit community](https://www.reddit.com/r/codeusse/) — we are happy to help.
---
# How Codeusse Uses tmux for Session Persistence
> Why server-side tmux matters on mobile SSH, how Codeusse names and configures sessions, and how to install tmux on macOS, Linux, and FreeBSD.
Coding over SSH from a phone or tablet means dealing with a **volatile client**: the OS may background your app, the network may drop, and SSH has to reconnect. None of that should wipe your shell history, your working directory, or the process you left running on the server. That is where **tmux** comes in — and why Codeusse builds its terminal experience around a dedicated tmux session on the host.
## What tmux gives you
**tmux** is a terminal multiplexer: it keeps one or more sessions alive on the **server**, independent of any single SSH connection. When you disconnect and come back, you can **attach** to the same session instead of starting from scratch. For mobile workflows, that turns “fragile pipe from phone to shell” into “reconnect and pick up where you left off.”
## Availability: often there, easy when it is not
Many Linux distributions ship tmux by default or include it in the base repositories. The binary is **small**, and packages exist for **macOS**, **BSD**, and essentially every mainstream Linux flavor. If your server does not have tmux yet, installing it is usually one package-manager command (see below). You do not need a heavy stack — just the `tmux` executable Codeusse can invoke over SSH.
## How Codeusse uses tmux
When you connect with Codeusse and tmux is available, the app prepares a **dedicated session** whose names use a **`codeusse-` prefix** so they stay separate from your own tmux sessions, scripts, or other tools on the machine. The interactive session Codeusse attaches to is named **`codeusse-main`**.
Codeusse ships a **custom tmux configuration** tailored for this workflow. The app uploads it to your account on the server; you can find it under **`$HOME/.codeusse`**, as `codeusse-tmux.conf`, alongside other Codeusse-managed files. That path is useful if you want to **inspect** what is being used or **back up** the directory. Editing the file by hand is possible but **unsupported** — unexpected changes might break assumptions the app makes when attaching or creating the session.
If tmux is not installed, not in `PATH`, or session setup fails, Codeusse **falls back to a plain shell** over SSH. In that case you still get a terminal, but long-running work may not survive disconnects the same way; the app may surface a **background warning** so you know persistence is limited.
## Installing tmux
Pick your system below. Each block includes a **“Best fit”** link that opens this article with that section highlighted — handy when you share instructions with teammates.
## Summary
tmux keeps your **server-side** work stable while your **mobile client** comes and goes. Codeusse names its session **`codeusse-main`**, uses a **`codeusse-` prefix** to avoid colliding with anything else on the host, and stores its tmux config under **`$HOME/.codeusse`**. Install `tmux` once on the machine you SSH into, and you are set for a much calmer coding session from your phone.
---
# How to Set Up SSH on a Raspberry Pi for Codeusse
> Flash Raspberry Pi OS with SSH enabled using Raspberry Pi Imager, set a username and password, find your Pi on the network, and connect from Codeusse.
Want to code on your Raspberry Pi from your phone? With Codeusse's SSH support and Raspberry Pi OS's SSH server, you can connect from anywhere on your local network and work in a full Linux environment. Here's how to set it up — from imaging the SD card to your first connection.
## What You'll Need
- A Raspberry Pi and a compatible microSD card (and a reader on your computer)
- A Mac or PC with [Raspberry Pi Imager](https://www.raspberrypi.com/software/) installed
- Your Pi and your mobile device connected to the same Wi-Fi network (or Ethernet on the same LAN)
- Codeusse installed on your phone or tablet
## Step 1: Install Raspberry Pi Imager
Download **Raspberry Pi Imager** from the [official Raspberry Pi software page](https://www.raspberrypi.com/software/) and install it on your computer. You'll use it to write Raspberry Pi OS to the microSD card and to **pre-configure SSH and your login** before the Pi ever boots.
## Step 2: Choose an OS and Customize
1. Insert your microSD card and open Raspberry Pi Imager.
2. Pick your device:
Click Next.
3. Pick a Raspberry Pi OS image (for example **Raspberry Pi OS (64-bit)** or **Raspberry Pi OS Lite (64-bit)** if you want a minimal system without a desktop).
Click Next.
4. Click **Choose Storage** and select your microSD card.
Click Next.
## Step 3: Apply Customization
Most of the settings should be configured by yourself. The guide will show you all of the customization screens with notes, on which settings will be relevant to the next steps of making Codeusse able to connect to your Pi.
> You can use the fields below to store the input you provided to your Pi, so the guide can be customized to your settings in the next steps.
> The values will not leave your device, and will be stored only in your browser.
## Step 4: Write Image
Click **Write** to flash the card. Wait until the write and verify steps finish, then eject the card safely.
## Step 4: First Boot
1. Put the microSD card into your Raspberry Pi and power it on.
2. Give it a minute or two on first boot (especially if it's expanding the filesystem or updating).
3. Confirm your Pi is on the same network as your phone (same Wi-Fi SSID, or same LAN if using Ethernet).
## Step 5: Find Your Raspberry Pi's Local IP Address
To connect from Codeusse, you need your Pi's IP address on the local network (it usually looks like `192.168.x.x` or `10.0.x.x`).
### Option A: Try the `.local` Hostname First
If you set a **hostname** in Imager (for example raspberrypi), try resolving it with **mDNS**:
- raspberrypi.local (replace with your hostname)
The default image often uses `raspberrypi` as the hostname, so **raspberrypi.local** may work if you didn't change it. You can test from a computer on the same network:
ping -c 3 raspberrypi.local
If ping works, you can use raspberrypi.local (or your-hostname.local) as the **Host** in Codeusse instead of the numeric IP.
### Option B: Your Router's Admin Page
Log in to your Wi-Fi router's admin interface (often printed on the router or documented in its manual). Look for **DHCP client list**, **connected devices**, or **LAN status**. Find the device named like your Pi's hostname or "raspberrypi" and note its **IP address**.
### Option C: From the Mac Terminal (ARP Scan)
After the Pi has been on for a minute, your Mac's ARP table may list it. This is quick but not always labeled clearly:
```bash
arp -a | grep -i "192.168\|10.0"
```
Compare with devices you know, or cross-check with the router list.
### Option D: If You Have a Monitor and Keyboard Attached
On the Pi itself, run:
```bash
hostname -I
```
The first address is typically your Pi's LAN IP.
> **Tip:** Local IP addresses can change when the router assigns them via DHCP. If your Pi's IP keeps moving, set a **DHCP reservation** or **static IP** for the Pi in your router's settings.
Write down the IP (or your working `hostname.local`) — you'll need it in the next step.
If you already know your Pi's IP address, you can enter it below so the connection details in Step 6 match what you found:
## Step 6: Connect from Codeusse
Open Codeusse on your phone or tablet and create a new SSH connection with these details:
- **Host**: Your Pi's IP address (e.g. 192.168.1.50) **or** raspberrypi.local if mDNS works on your network
- **Port**: `22` (the default)
- **Username**: The username you set in Raspberry Pi Imager (Step 3), e.g. pi
- **Authentication**: Password — use the **same password** you configured in Imager (not your Wi-Fi password), e.g. your SSH password
Tap **Save**. Then tap the newly created connection to open a session on your Pi.
> **iOS will ask for Local Network access.** The first time you connect, iOS may ask whether Codeusse can access devices on your local network. Tap **Allow** — this permission is required for Codeusse to reach your Pi over Wi-Fi. Without it, the connection will fail.
You now have an active SSH session on your Raspberry Pi. You can install tools, edit files, run services, and use the same workflows you'd use from a desktop terminal.
## Troubleshooting
### "Connection refused" error
- Confirm **SSH** was enabled in Raspberry Pi Imager before writing the card (Step 3).
- Make sure the Pi finished booting and is online (LED activity, or try `ping` to its IP).
- Double-check the **IP address** or **hostname.local** — typos are common.
### "Connection timed out" error
- Ensure your phone and the Pi are on the **same network** (same SSID for Wi-Fi; or same LAN segment for Ethernet).
- If you use a **guest Wi-Fi** network, many routers **isolate** clients from each other — use the main LAN Wi-Fi or adjust router settings.
- Some routers or firewalls block device-to-device traffic; check **AP isolation** / **client isolation** is off.
### "Permission denied" error
- Verify the **username** and **password** match what you set in **OS customization** in Imager (not your Apple ID or router password).
- If you only enabled **public key** authentication in Imager, password login will fail — re-flash with **password authentication** or add your key.
### `hostname.local` Does Not Resolve
- Not all networks forward mDNS reliably. Fall back to the **numeric IP** from your router or `hostname -I` on the Pi.
## What's Next?
Once you're connected over SSH, you can:
- **Edit files** on your Pi using Codeusse's editor
- **Run development servers** and reach them from your mobile browser (using the Pi's IP and the right port)
- **Use Git**, package managers, and your usual Linux tooling
- **Set up SSH keys** so you don't have to type your password each time
---
Have questions or ran into an issue? Drop by our [Reddit community](https://www.reddit.com/r/codeusse/) — we're happy to help.
---
# How to Enable the SSH Server on Your Mac
> Step-by-step guide to turning on Remote Login (SSH) on macOS so you can connect to your Mac from Codeusse over your local network.
Want to code on your Mac from your phone? With Codeusse's SSH support and macOS's built-in SSH server, you can connect to your Mac from anywhere on your local network and work with your full development environment. Here's how to set it up.
## What You'll Need
- A Mac running macOS Ventura (13) or later
- Your Mac and your mobile device connected to the same Wi-Fi network
- Codeusse installed on your phone or tablet
## Step 1: Open Sharing Settings
macOS has a built-in SSH server — Apple calls it **Remote Login**. You just need to turn it on.
Open **System Settings** and navigate to **General → Sharing**. You can get there quickly by clicking this link from your Mac:
[Open Sharing Settings](x-apple.systempreferences:com.apple.Sharing-Settings.extension)
Or, open **Terminal** and run:
```bash
open "x-apple.systempreferences:com.apple.Sharing-Settings.extension"
```
## Step 2: Enable Remote Login
Find **Remote Login** in the sharing services list and toggle it **on**. macOS will start the SSH server immediately.
### A Note on Full Disk Access
macOS protects certain folders — including **Documents**, **Downloads**, and **Desktop** — even over SSH. If your projects live in one of these directories, you may see "Operation not permitted" errors when trying to access them.
To fix this, you need to grant **Full Disk Access** to the SSH server process:
Then toggle "Allow full disk access for remote users" on:
Finally, click "Done" to save the changes.
## Step 3: Note Your Username
You'll need your macOS username to connect via SSH. If you're not sure what it is, open **Terminal** and run:
```bash
whoami
```
This prints your short username — the one you'll use to log in. For example, if the output is `alex`, your SSH login will be `alex@`.
## Step 4: Find Your Mac's Local IP Address
To connect from Codeusse, you need your Mac's IP address on the local network. There are a few ways to find it.
### Option A: From System Settings
Navigate to **Wi-Fi** in System Settings (or click the link below):
[Open Wi-Fi Settings](x-apple.systempreferences:com.apple.Wi-Fi-Settings.extension)
Click **Details…** next to your connected network. Your IP address will be listed under **TCP/IP** — it typically looks like `192.168.x.x` or `10.0.x.x`.
Then,
### Option B: From Terminal
Run one of these commands:
```bash
ipconfig getifaddr en0
```
This returns your Wi-Fi IP address directly. If you're using Ethernet, try `en1` instead, or use this command to list all active interfaces:
```bash
ifconfig | grep "inet " | grep -v 127.0.0.1
```
Write down or memorize this IP address — you'll need it in the next step.
> **Tip:** Local IP addresses can change if your router assigns them dynamically (DHCP). If your Mac's IP changes frequently, consider assigning it a static IP or a DHCP reservation in your router's settings.
## Step 5: Connect from Codeusse
Open Codeusse on your phone or tablet and create a new SSH connection with these details:
- **Host**: Your Mac's IP address (e.g. `192.168.1.42`)
- **Port**: `22` (the default)
- **Username**: Your macOS username from Step 3
- **Authentication**: Password (your current Mac password, not Apple ID password)
Tap **Save**. Then, tap the newly created connection to enjoy your work setup in your palm.
> **iOS will ask for Local Network access.** The first time you connect, iOS will show a prompt asking whether Codeusse can access devices on your local network. Tap **Allow** — this permission is required for Codeusse to reach your Mac directly over Wi-Fi. Without it, the connection will fail.
You now have an active session on your Mac. Run builds, manage Git repos, use your favorite CLI tools — all from your phone.
## Troubleshooting
### "Connection refused" error
- Double-check that Remote Login is turned on in System Settings.
- Make sure both devices are on the same Wi-Fi network.
- Verify the IP address hasn't changed since you looked it up.
### "Connection timed out" error
- Your Mac's firewall might be blocking SSH. Go to **System Settings → Network → Firewall** and ensure that incoming connections to the SSH service are allowed. When Remote Login is enabled, macOS typically adds a firewall exception automatically, but it's worth verifying.
[Open Firewall Settings](x-apple.systempreferences:com.apple.Network-Settings.extension)
### "Permission denied" error
- Verify that your username and password are correct.
- If you restricted Remote Login to specific users, make sure your account is in the allowed list.
## What's Next?
Once you're connected over SSH, you can:
- **Edit files** directly on your Mac using Codeusse's editor
- **Run development servers** and access them from your mobile browser
- **Use Git** to push and pull code
- **Set up SSH keys** so you don't have to type your password each time
---
Have questions or ran into an issue? Drop by our [Reddit community](https://www.reddit.com/r/codeusse/) — we're happy to help.
---
# Welcome to the Codeusse Blog
> Introducing the official Codeusse blog — your go-to source for updates, tips, and insights about mobile development with Codeusse.
I'm excited to launch the official Codeusse blog! This is where I'll be sharing updates about the app, tips for mobile development, and insights from the world of coding on the go.
## What to Expect
I have a lot planned for this blog. Here's a taste of what's coming:
- **Product updates** — Learn about new features as they ship, including deep dives into how they work and how to get the most out of them.
- **Mobile development tips** — Practical advice for coding effectively on your phone or tablet.
- **Community highlights** — Stories from the Codeusse community and how developers around the world are using the app.
- **Behind the scenes** — A look at the technical decisions and design philosophy behind Codeusse.
## Why a Blog?
I believe in building in the open. A blog gives me a space to share my thinking, explain my decisions, and stay connected with the community beyond quick social media posts.
Whether you're an early adopter who's been with us from day one, or you just discovered Codeusse, I hope you'll find something useful here.
## Stay Connected
Don't miss a post — join our [Reddit community](https://www.reddit.com/r/codeusse/) to discuss new articles and share your own experiences. You can also reach me at [codeusse@wrbl.xyz](mailto:codeusse@wrbl.xyz) with suggestions for topics you'd like me to cover.
Happy coding!
---