Forem: Matthias Steinbauer

The Machine Keeps Up. You Don't. Building a Second Screen for Claude Code.

Matthias Steinbauer — Wed, 11 Feb 2026 08:51:00 +0000

The Machine Keeps Up. You Don't. Building a Second Screen for Claude Code.

Anthropic keeps telling us: run multiple Claude Code sessions in parallel. It's right there in the docs, in the blog posts, in every "advanced tips" thread. And they're right — it works. You can have one session refactoring your auth module, another fixing a gnarly CSS bug, and a third writing tests. Claude handles context across all of them just fine.

The machine isn't the bottleneck. You are.

Three screens, three contexts. Left: Claude Code doing its thing. Center: the app we're building. Right: the dashboard keeping it all together.

The Problem With Parallel Sessions

When you're running 3-5 Claude Code sessions simultaneously, things get chaotic fast. You Alt-Tab between terminals and forget which session was doing what. One session finished five minutes ago and is waiting for your input — but you didn't notice because you were deep in another one. You lose track of which GitHub issues are being worked on where.

Claude's context window is great. Human working memory? Not so much.

We needed a way to see all our sessions at a glance without switching between terminals. Something like a mission control for Claude Code.

So We Built One (With Claude, Obviously)

We vibecoded a dashboard that solves exactly this problem. It's called claude-second-screen, and it does one thing well: it gives you a real-time overview of all your active Claude Code sessions.

Here's what each session card shows you:

🟢 Green — Session is idle, work is done
🟡 Yellow — Claude is actively working
🔴 Red — Session is waiting for YOUR input (this is the important one)

Beyond the color coding, each card displays a short summary of what's happening in that session and which GitHub issues are being worked on. No more "wait, which terminal was fixing issue #47?"

How It Works

The architecture is dead simple. A lightweight local server runs the dashboard on localhost:3456. Claude Code sessions report their state via hooks — the same hooks system that Claude Code already provides.

Four hooks handle everything:

SessionStart — registers a new session on the dashboard
UserPromptSubmit — marks the session as busy (yellow)
Stop — marks the session as idle (green)
Notification — marks the session as waiting for input (red)

There's also a skill file you drop into your .claude/skills/ directory. This teaches Claude to update the dashboard with summaries and issue references as it works. Claude essentially self-reports what it's doing.

Setup in 2 Minutes

git clone https://github.com/steima/claude-second-screen
cd claude-second-screen
npm install
npm run build
npm start

Then copy the skill file and add the hooks to your .claude/settings.json:

{
  "hooks": {
    "SessionStart": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "bash /path/to/claude-second-screen/hooks/register-session.sh"
      }]
    }],
    "Stop": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "bash /path/to/claude-second-screen/hooks/set-idle.sh"
      }]
    }],
    "Notification": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "bash /path/to/claude-second-screen/hooks/notify-waiting.sh"
      }]
    }]
  }
}

Open http://localhost:3456 on your second monitor. Done.

Why a Dedicated Dashboard?

You might ask: why not just use tmux panes or terminal tabs? Because the point isn't to see the terminal output. The point is to see the status and intent of each session at a glance. A wall of terminal text doesn't tell you "this session is blocked on you" — a red card does.

It's the difference between monitoring raw logs and having a proper dashboard. When you're juggling 3+ parallel sessions, you want the 10,000-foot view, not the ground-level terminal scroll.

The Meta Part

Yes, we built this tool with Claude Code. Yes, we ran multiple sessions in parallel to do it. And yes, we desperately needed the dashboard while building the dashboard. Dogfooding at its finest.

Try It Out

The repo is open source (MIT): github.com/steima/claude-second-screen

If you're running multiple Claude Code sessions and feel like you're the one dropping context — not the AI — give it a shot. It's a small tool that solves a real workflow problem.

We're building .LOUPE, a GRC compliance platform, and Claude Code is a core part of our development workflow. This dashboard came out of our daily frustration with losing track of parallel sessions. If you have ideas or improvements, PRs are welcome.

Stop Rewriting Your API: How FMiddleware Lets You Deploy to Lambda AND Express with Zero Code Changes

Matthias Steinbauer — Wed, 28 Jan 2026 13:31:48 +0000

The Problem: Serverless Lock-In Is Real

You started with AWS Lambda even used a framework like Serverless.com. It made sense—no servers to manage, pay-per-use pricing, and quick deployments. Life was good.

Then you tried to debug something locally.

The reality is that local development with Lambda is painful. You're constantly dealing with mocked API Gateway events, environment differences between local and deployed code, and debugging workflows that don't match how you'd normally work with Node.js. When something breaks in production, reproducing it locally means wrestling with event structures and Lambda-specific context objects.

And if your team ever decides to move to Docker or Kubernetes? Your entire codebase is tied to Lambda's event structure—migration means rewriting your API layer.

The Solution: Write Once, Deploy Anywhere

What if you could write your API handlers once and deploy them to any runtime without changing a single line of business logic?

That's exactly what FMiddleware does.

FMiddleware is a framework-agnostic HTTP middleware library that abstracts away the runtime differences between AWS Lambda and Express.js. Your handlers stay the same—only the deployment wrapper changes.

Quick Start: See It In Action

Install the package:

npm install @loupeat/fmiddleware

Define your API handler once:

import { FRequest } from "@loupeat/fmiddleware";

interface Note {
  id: string;
  title: string;
}

// This handler works on BOTH Lambda and Express
api.get("/api/notes", async (request: FRequest<any, any>) => {
  const notes: Note[] = [{ id: "1", title: "Hello World" }];
  return api.responses.OK<any, Note[]>(request, notes);
});

Deploy to Express.js (Local Dev / Docker)

import express from "express";
import { FExpressMiddleware, FRequest } from "@loupeat/fmiddleware";

const app = express();
const api = new FExpressMiddleware();

// Register your routes (same as above)
api.get("/api/notes", async (request: FRequest<any, any>) => {
  const notes = [{ id: "1", title: "Hello World" }];
  return api.responses.OK(request, notes);
});

// Use FMiddleware as Express middleware
app.use(express.json());
app.all("*", async (req, res) => {
  const response = await api.process(req);
  res.status(response.statusCode).json(response.body);
});

app.listen(3000);

Deploy to AWS Lambda (Production)

import { APIGatewayProxyHandler } from "aws-lambda";
import { FAWSLambdaMiddleware, FRequest } from "@loupeat/fmiddleware";

const api = new FAWSLambdaMiddleware();

// Same exact handler code!
api.get("/api/notes", async (request: FRequest<any, any>) => {
  const notes = [{ id: "1", title: "Hello World" }];
  return api.responses.OK(request, notes);
});

export const handler: APIGatewayProxyHandler = async (event) => {
  return api.process(event);
};

Notice something? The handler code is identical. Only the wrapper changes.

Why This Matters for Developer Productivity

1. Seamless Local Development

No more mocking Lambda events or fighting with local emulators. Just run your Express server locally and test like any normal Node.js app:

npm run dev  # Uses Express wrapper

When you're ready for production, deploy with your Lambda wrapper—zero code changes.

2. Easy Migration Path

Already on Lambda and want to move to Docker? Simply:

Swap FAWSLambdaMiddleware for FExpressMiddleware
Add a Dockerfile
Deploy

Your handlers, validation, authentication—everything stays the same.

3. Hybrid Deployments

Running some endpoints on Lambda for cost efficiency and others on ECS for performance? FMiddleware lets you share the exact same handler code across both.

Batteries Included: Features That Actually Help

FMiddleware isn't just a wrapper—it's a full-featured API toolkit:

TypeScript-First

Full type safety for requests and responses:

interface CreateNoteRequest {
  title: string;
  content: string;
}

api.post<any, CreateNoteRequest>("/api/notes", async (request) => {
  const { title, content } = request.body; // Fully typed!
  // ...
});

Built-in JSON Schema Validation

const CreateNoteSchema = {
  type: "object",
  properties: {
    title: { type: "string", minLength: 1 },
    content: { type: "string" },
  },
  required: ["title", "content"]
};

api.post("/api/notes", async (request) => {
  // request.body is automatically validated
  const { title, content } = request.body;
  // ...
}, CreateNoteSchema);

Pre-Processors for Authentication

const AuthPreProcessor: RequestPreProcessor = {
  name: "AuthPreProcessor",
  pathPatterns: ["/api/notes/*"],
  requestSources: "*", // Works on both Express and Lambda
  process: async ({ request }) => {
    const authHeader = request.headers["authorization"];
    if (!authHeader) {
      throw new AuthenticationError("Missing authorization header");
    }
    const token = authHeader.replace(/Bearer /, "");
    const user = await authService.verifyToken(token);
    request.context["user"] = user;
  }
};

api.addRequestPreProcessor(AuthPreProcessor);

Semantic Error Classes

import {
  ValidationError,      // 400 Bad Request
  AuthenticationError,  // 401 Unauthorized
  ForbiddenError,       // 403 Forbidden
  NotFoundError,        // 404 Not Found
  ConflictError,        // 409 Conflict
} from "@loupeat/fmiddleware";

// Errors automatically map to correct HTTP status codes
if (!note) {
  throw new NotFoundError(`Note ${noteId} not found`);
}

OpenAPI Generation

Automatically generate OpenAPI 3.0 specs from your handlers:

import { FExpressMiddleware, OpenAPIMetadata } from "@loupeat/fmiddleware";

api.get("/api/notes", async (request) => {
  const notes = await notesService.list();
  return api.responses.OK(request, notes);
}, {
  summary: "List all notes",
  description: "Retrieves all notes for the authenticated user",
  tags: ["Notes"],
});

Real-World Deployment

FMiddleware works with any deployment tool—Serverless Framework, AWS CDK, SST, or plain CloudFormation. Here's an example using Serverless Framework:

service: notes-api

plugins:
  - serverless-esbuild

provider:
  name: aws
  runtime: nodejs20.x
  region: eu-west-1

functions:
  api:
    handler: src/handler.main
    events:
      - http:
          method: any
          path: "api/{proxy+}"
          cors: true
    timeout: 15

When to Use FMiddleware

FMiddleware is perfect if you:

Want flexibility to switch between serverless and containerized deployments
Value local development experience that mirrors production
Need a migration path away from Lambda without rewriting everything
Want type-safe APIs with built-in validation
Prefer framework-agnostic code that doesn't lock you in

Get Started Today

npm install @loupeat/fmiddleware

# For AWS Lambda support
npm install --save-dev @types/aws-lambda

Check out the full documentation and examples:

GitHub: loupeat/fmiddleware
npm: @loupeat/fmiddleware

Have you dealt with serverless lock-in? How did you handle the migration? I'd love to hear your experiences in the comments!

FMiddleware is open source and MIT licensed. Contributions welcome!