RIG

1 sleeping Mac can interrupt the handoff: The client needs the local build, but the Mac running it is asleep. Rig Mesh offers private Mac-to-Mac networking and Remote Wake, without making the dev service public. Try Rig in public beta.

Reopening a Laravel project after work: check each process and its latest log before restarting. Forgotten state and scattered logs can eat your first useful stretch. Rig puts processes and logs together in one Mac app. Try Rig in public beta.

Oct 15: Xcode 27.1 shipped. 27.2 beta 3: Oct 14. Check process args + build ID before blaming source.

When Laravel, Vite and a queue worker live in separate terminal tabs, it’s easy to lose track of what’s running. Rig starts and organises project processes in one window, with status and logs together. Try Rig in public beta.

Laravel server, queue worker and database in separate tabs? Add them as local processes in Rig; their logs share one window. Containers are useful when needed, not just for visibility. Try Rig in public beta.

A local project can fail because one supporting process has stopped, even while the rest is running. Rig detects crashes and keeps project processes visible in one Mac window. Try Rig in public beta.

Your Mac at home is asleep; the project you need is on it. The usual assumption that you must wait isn’t always right: Rig’s optional remote wake wakes it before you connect, and Mesh provides private Mac-to-Mac networking. Try Rig in public beta.

Sandboxing sets boundaries for where an agent can run. Runtime visibility is a separate layer: see which process owns a port, then read its logs. Rig brings local processes, ports, and logs into one window.

A beta should be clear about its boundaries. Rig runs and organises local development processes from one window; WordPress management and remote deployment are deferred, not features to rely on today. That distinction matters when deciding what belongs in your workflow. Try Rig in public beta.

Claude sees a Laravel repo, but localhost:8000 is served by the wrong process. Check which process owns port 8000 before changing code: repository context isn’t environment context. Rig’s MCP connection exposes local process state. Try Rig in public beta.

Claude can read your Laravel code. It can’t see your stopped queue worker. Connect Rig’s MCP to live local state; check worker status and database reachability before tracing Laravel code. That tells you whether to debug the app or restore a dependency. Try Rig in public beta.

1 green dot is a weak definition of ‘working’: it tells you a process exists. A useful beta should show which project process is running and its logs, so status points to real activity instead of another dashboard. Try Rig in public beta.

Claude rewrites a route when localhost doesn’t respond; the real issue may be a stopped service. Check local processes and logs through MCP before editing. Rig exposes that context to Claude and Cursor. Try Rig in public beta.

A Node API and React dev server can both be running, but a terminal full of commands makes it hard to see which process belongs to which project—or what to stop. Rig organises project processes in one window. Try Rig in public beta.

Port 3000 is busy. Source code won’t tell an agent which process owns it. With a live view of local processes over MCP, it can check what’s running before proposing a fix.

Synced files can get your project onto the laptop, but they won't wake the Mac running it. Rig Mesh connects your Macs privately and supports remote wake, so you can reach that development environment. Try Rig in public beta.

Illustrative: [14:03] worker exited. Keep its logs after restart; the useful line may click later.

Coming back to a project after work can mean figuring out which local processes are still running. Rig keeps project processes and combined logs in one window, ready to inspect. Try Rig in public beta.

3000: Claude proposes changing localhost:3000, but a stale Node process still owns that port. Changing config won't release the socket; the live process context matters. Rig's MCP access exposes local process and port context. Try Rig in public beta.

Rig in 60 Seconds. Easy.

Running Laravel, a frontend, a database, and a worker in separate terminals gets noisy fast. Put them in Rig for one status view and shared logs; your runtimes stay right where they are.

We've watched AI agents confidently suggest localhost:3000, only for developers to discover PID 8421 already owns it. The agent never saw running processes, logs, or port state. MCP bridges that gap: our tooling reads live process bindings alongside your code.

An AI agent rewrites your config at 14:07. The process still holds the socket from 13:52. More code context doesn't fix that gap. You need to see it happening in real time, which is exactly why we built Rig around one visible log stream instead of scattered terminal tabs.

Green is not healthy. A process can report running while its queue hasn't processed a job in twenty minutes. Status boards lie. Watch the heartbeat.

MCP tools are more useful with runtime context, not just source code. Rig connects clients like Cursor and Claude to your local environment, with processes, ports, and logs together in one window. Debugging has more to go on.

A green status can hide a stuck worker. At 10:14, the web process returned 200, but the worker had no fresh log line. Your app may look healthy while background jobs have stopped moving. Check the timestamps, heartbeat, and process state before trusting the status.

When localhost:5173 won't bind, lsof -i :5173 shows what's holding the port. Rig keeps that state visible alongside your project processes, so you can track the conflict from one window.

14:06:12 job.created. Queue stalls. Correlate worker timestamps: activity means slow work; silence means the worker stopped emitting. Logs are a timeline, not decoration.

It's 11pm. You're at the kitchen table with a client issue. Your office Mac is asleep. Remote access tools assume the machine is awake and reachable. Rig Mesh wakes it first, then connects you. That's the actual problem we solved. Try Rig in public beta.

We built Rig because we kept running into the same wall: Claude would suggest a port change, but our local server was still listening on 3000, and Claude had no way to know. It's a visibility problem that costs real time in real development cycles.

More terminal tabs do not mean more control. Six windows, stale scrollback, repeated process checks. One visible operational picture actually tells you what's running: process trees, live logs, exit codes, all in one place.

Docker sandboxed the agent, but localhost still needs visibility. Isolation protects execution; debugging needs live process state, ports, and logs in one place. That's where the real work happens.

We built Rig because we kept running into the same wall: Claude would suggest a port change, but our local server was still listening on 3000, and Claude had no way to know. It's a visibility problem that costs real time in real development cycles.

AI assistants confidently suggest changing localhost:3000. A developer runs the command, nothing works, and lsof reveals a stale Node process still holding the port. Twenty minutes gone. The assistant never saw what was actually running. We built Rig to show you and your tools the same thing.

Drum roll please. Right, the drummer's been let go. Introducing Snag. Your client clicks. You get the screenshot, the device and the server logs. No staging, no client account, clients never pay. Join the waitlist at snag.userig.app. There's a surprise. It isn't a newsletter.

Six terminal tabs every morning, and one of them has always crashed. Rig runs your whole dev stack in one window, and your AI can see it too. Free on Mac. Made in the UK. userig.app #webdev #laravel #macapps #developer #coding

We built Rig because watching three developers on the same project fight over ports and then guess at logs got old fast. One person runs Laravel on 8000, another's Valet claims it first, a third has a stray process nobody can name.

You're running Laravel and Vite. Both report green. The queue worker logs say it's processing, but nothing's moved in twenty minutes. You check lsof. You check ports. You kill what you think is the old Node process. Still stuck.

An agent with repository access can read your Laravel code, but it won't see that localhost:3000 is already bound to an old Node process, or that your queue worker stopped processing jobs an hour ago. MCP fills the code gap. It doesn't fill the observability gap.

You're running Docker, Vite, and Postgres. All three report green. Your queue worker is also running. But eighteen minutes have passed since it processed anything, and you won't know that by looking at status lights.

The bug is often not in the code. It's in the state. A stale worker, a port still held by a crashed process, a schema drift between migrations and what's running, a queue that never recovered from a restart.

MCP clients can call tools, but agents can't fix what they can't see. Your AI needs live process, port, and log context, not just repo files.

Running lsof -i :3000 for the third time because you forgot which process claimed that port. Again. The instinct is to open another terminal tab. But the real problem isn't the number of windows. It's that processes, logs, ports, and restart state live scattered across them.

Our new blog article: "The App Is Running" Is Not a Status is out today: userig.app/blog/the-app...

Would you trust a fix from an agent that cannot see localhost:3000? When it suggests changing the port while Node still owns it, you restart, and nothing runs. Local context matters. An AI tool blind to your actual environment makes confident guesses that break your setup.

When Claude suggests a fix for a port conflict or crashed process, it's guessing blind if it can't see what's actually running on your machine. Port 3000 is taken by Rails. Port 5432 is Postgres. The last error was a missing env var at 14:32.

Your Mac is running six different terminals right now and you've forgotten what half of them are for. Rig puts all of it in one window. userig.app

Built for teams. Rig's cloud features let you manage devices, share projects securely, add team seats, and back up your local work encrypted. Start solo on Mac, bring your team in when you're ready. Free tier, paid plans for collaboration.

Rig connects your AI tools directly to your local environment. Cursor, Claude, and other MCP clients can see what's running, spot port conflicts, read logs, and suggest fixes without leaving your editor. Your whole dev setup, visible to your AI.

Rig just launched. One window for every process in your project. Logs merged, ports managed, crashes caught. Run your whole local stack from one board instead of juggling tabs and terminals. CLI and Mac app. Free to start.