DEV Community: Abe Wheeler

Shared, hosted memory

Abe Wheeler — Thu, 30 Jul 2026 19:49:34 +0000

We just launched shared and hosted Memory in Alignbase.

Alignbase is now your headless, model-agnostic place to govern and coordinate:
🤖 Agents
🗂️ AGENTS.mds
🔧 Skills
+ 🧠 Memory!

AI agents often start each session without the working context they built last time. Alignbase now gives each agent one hosted Memory file it can read every session and update as it works.

Teams can:

Automatically create a writable Memory for every new agent
Share one Memory file across any number of agents
Turn write access off per agent while keeping Memory readable
Track version history and agent activity in one place

Agents manage their own Memory, so users do not have to review every update. Memory holds current tasks, decisions, learned preferences, and known traps.

It stays separate from AGENTS.md instructions, Skills, and full knowledge bases.

Agents now pick up where any other agent left off!

See it at https://alignbase.ai

I Built a Git-Native SOC 2 Tool Because I Didn’t Want Another SaaS Bill

Abe Wheeler — Tue, 28 Jul 2026 14:30:29 +0000

I recently posted this on X:

Didn’t feel like paying a zillion dollars again for basic SOC 2 software, so I rolled my own this weekend.

100% file-based, uses Git for audit trails. Agents can absolutely cook on this thing.

That post got far more attention than I expected, so I thought developers might want a closer look at the idea and how it works.

The project is called filegrc. It is an open source, Git-native system for managing SOC 2 records and audit evidence.

The problem I wanted to solve

A lot of SOC 2 work is structured data wrapped in a web application:

Policies and their approval state
Controls, owners, and implementation details
Recurring security work
Risks, vendors, systems, and incidents
Evidence collected during an audit period
Links between all those records

Engineering teams already have a good system for reviewing structured text, tracking changes, assigning authorship, and preserving history.

That's Git.

I wanted to see what SOC 2 work would look like if the repository were the system of record.

The basic architecture

filegrc stores structured records as JSON and long-form content as Markdown.

A workspace looks roughly like this:

company-grc/
├── AGENTS.md
├── data/
│   ├── policies/
│   ├── systems/
│   ├── risks/
│   ├── obligations/
│   ├── evidence/
│   ├── audits/
│   └── workspace.json
├── package.json
└── README.md

A policy record might contain fields such as:

{
  "schemaVersion": 1,
  "id": "policy-information-security",
  "type": "policy",
  "title": "Information Security Policy",
  "status": "draft",
  "ownerIds": ["person-policy-owner"],
  "approverIds": ["person-independent-approver"],
  "version": "1.0",
  "effectiveOn": "2026-08-01",
  "reviewCadence": {
    "mode": "calendar",
    "unit": "year",
    "interval": 1,
    "anchorDate": "2026-08-01"
  }
}

The policy text lives beside it:

data/policies/policy-information-security.json
data/policies/policy-information-security.md

The engine keeps data structured when it needs to validate, filter, calculate deadlines, or connect records. Policies, procedures, meeting notes, audit responses, and other long-form work stay in Markdown.

Why Git works well here

Git already records:

What changed
Who changed it
When the change entered the repository
The exact diff
The revision containing the change
The review that approved it

That removes the need for a second application-level change log.

Domain dates still need to remain explicit. A control test performed on July 10 needs a completedOn date, even if someone commits the record on July 11. Git records the repository change. The record describes what happened in the security program.

Keeping those concepts separate makes the history easier to inspect.

It also makes normal engineering workflows available:

git diff
git blame data/policies/policy-information-security.md
git log -- data/controls/control-access-review.json

A reviewer can examine a policy change using the same tools they use for code.

The files still need a domain model

Putting JSON in Git is the easy part. The harder part is enforcing the relationships and lifecycle rules that make the records useful.

filegrc has a versioned model registry that defines:

Resource types
Required fields
Valid values
Relationships
Conditional requirements
Markdown content slots
Default UI metadata

The validator, CLI, browser forms, search index, and generated documentation all consume that model.

This means the browser and CLI do not have separate ideas about what a valid control or evidence record looks like.

You can validate an entire workspace with:

npm run validate

The validator checks individual records as well as relationships between them.

For example, it can detect missing owners, broken references, invalid date ranges, incomplete policy events, missing Markdown, and evidence attachments that resolve outside the workspace.

Headless use is part of the product

I wanted coding agents to work with filegrc without learning the whole model from scratch.

A generated workspace includes agent instructions, and the CLI exposes model-driven guidance:

npx filegrc guide risk-assessment --json
npx filegrc list risk --json
npx filegrc references system-id --json
npx filegrc scaffold risk-assessment \
  --title "2026 Annual Risk Assessment"

An agent can ask which fields a record requires, inspect valid relationship targets, scaffold a mutation, and run validation afterward.

Recurring and event-driven work is available through the CLI too:

npx filegrc obligations --json

npx filegrc trigger person-started \
  --occurred-on 2026-07-25 \
  --subject person-id

npx filegrc complete-action action-item-id \
  completion-record.json \
  --completed-on 2026-07-25

The browser and CLI call the same domain functions, so an agent receives the same validation and calculations as a person using the UI.

That is what I meant when I said agents can cook on this thing.

A zero-dependency Node.js engine

The filegrc engine uses Node.js built-in modules only.

It does not require a database, compilation step, bundler, or hosted service. It runs locally, in CI, or in a basic server environment with Node.js 20 or newer and Git.

The engine handles:

Workspace validation
CRUD operations
Search
Recurring obligations
Policy-triggered events
Program and audit readiness checks
Evidence packet generation
A local web interface

Writes are atomic, paths are checked against the workspace boundary, and CRUD commands do not create Git commits unless the user explicitly asks for one.

What filegrc does not replace

filegrc manages GRC records and audit evidence. It does not replace infrastructure logging, identity management, backups, endpoint protection, monitoring, training, or incident detection.

Those systems remain the authoritative sources.

filegrc catalogs them, records how evidence should be collected, and connects their exports or reports to the relevant controls and audit work.

It also does not decide whether a company is compliant. The organization has to operate its controls, and the independent CPA firm still evaluates the evidence and performs the audit.

Try it locally

You can create a workspace with:

npx create-filegrc@latest company-grc
cd company-grc
npm run validate
npm run serve

The generated repository starts with draft records and setup work. The starter content is a proposal, not a claim about how your company operates.

Review it, change it, and commit the version that reflects reality.

Sunpeak-AI / filegrc

Git & file-based SOC 2

filegrc

Run a SOC 2 program as files in Git.

filegrc gives a founder-led engineering team one place to adopt policies, implement controls, test External Evidence collection, run recurring compliance work, and prepare an audit. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history.

There is no separate application database. The repository is the program, so engineers and agents can use the same data through the web app, a text editor, or the CLI.

Why it exists

SOC 2 work tends to scatter across documents, calendars, tickets, screenshots, and the auditor’s request list. That makes it hard to answer basic questions: What is due? Which policy requires it? What changed during the audit period? Is the evidence complete?

filegrc keeps that work connected:

A starter Security program links criteria references, policies, planned controls, owners, and schedules.
Work Queue turns policy timing into upcoming, due, and…

View on GitHub

Which security and compliance records would you keep in Git, and which ones belong in their source systems?

Auditable Agent Context 🔍

Abe Wheeler — Wed, 15 Jul 2026 17:03:24 +0000

We just shipped agent context audits at Alignbase! Now you can know exactly what your agents knew, every time they acted.

When an agent takes action, Alignbase records the context bundle behind that run: the policies, AGENTS.md entries, Skills, versions, tags, and routing decisions that shaped the session. That gives teams a point-in-time record they can inspect later instead of guessing which instructions were present.

This helps with review, debugging, and governance. If an agent misses a rule or follows stale guidance, you can trace the input path, fix the source context, and prevent the same failure from spreading across the rest of the fleet.

The Memento Problem

Abe Wheeler — Fri, 10 Jul 2026 18:18:02 +0000

Memento wasn't a great movie, but Alignbase's new Agent Proposals is a great solution to what I like to call "The Memento Problem":

Agents on the front-line are grappling with the same questions & roadblocks every single session. They come up with their own solutions and complete the task at hand, but those solutions are unshared and discarded. Next startup, they do it all over again.

Not anymore! Alignbase lets your agents store their learnings in team-wide AGENTS .md and Skill files, and injects them into every agent on your team BEFORE those agents discover the question again.

Alignbase is the place for teams & agent fleets to manage shared context and learn as a collective! It's a way better solution than tattoos.

The Alignbase Skills Repository

Abe Wheeler — Thu, 02 Jul 2026 16:23:13 +0000

Introducing the Alignbase Skills repository! With Skills, Alignbase is the place for teams to collaborate on ALL shared context, from the context your team's agents MUST use (like AGENTS.md) to the context they CAN use (Skills).

Today, Alignbase brings fully managed context (auth, permissions, audits, reviews, and versioning) and a single source of truth to your internal Skills as well.

Like all things Alignbase, the Skills repository works in the background across Claude Code, Cowork, Codex, Cursor, ChatGPT, or anywhere you use models, whether that's web, desktop, CLI, or some other custom harness!

We need a company-wide AGENTS.md

Abe Wheeler — Tue, 23 Jun 2026 11:48:51 +0000

Introducing Alignbase: your company-wide AGENTS.md

The engineers that used to write the code knew the company, product, and policies. Now, the agents writing the code don’t.

It’s easy to give agents access to the internal wiki or Skills repo, and those solutions have their place. It’s one thing to give agents context they CAN use and another to inject context they MUST use.

The AGENTS.md forces context uptake within a code repository, but these files are static and they don’t cross repo, user, and web agent boundaries cleanly. Alignbase unifies shared context under a single remote repository.

Context needs to be treated as a first-class citizen. It’s scarce and it’s valuable. Context needs optimization, authentication, permissions, audits, and approvals. Alignbase does that. Wikis, Skills, AGENTS.md, and “company brains” don’t.

That shared Github repo isn’t enough. Who’s allowed to define what the company is? What the team’s policies are? Is that enforced? Is access authenticated? Is delivery dynamic? How do you immediately tell all your company’s agents about your ongoing AWS outage?

Alignbase is the first shared context repository and context control plane. Grateful for any and all feedback!

https://alignbase.ai/

How do you know budget models are smart enough for your MCP server?

Abe Wheeler — Tue, 14 Apr 2026 18:23:12 +0000

We just shipped evals for sunpeak.ai

The #1 thing I hear from MCP server teams: “Our tools worked great with the latest models, but we had to start from scratch when we realized the free models couldn't use them at all.”

Budget models call tools differently: they misread ambiguous schemas, they pass wrong arguments, they can't chain tool calls, and you don’t find out until users complain.

sunpeak evals test your MCP server across every model that matters, in one command. 100% on GPT-4o, 40% on Gemini Flash. That 40% is a schema problem you’d never catch testing manually on ChatGPT. Fix the tool architecture + description, run it again, and watch it climb to 95%.

Works with any MCP server. sunpeak connects over MCP, discovers your tools, and runs each eval case dozens of times per model so you get a real pass rate, not a single lucky result.

Put it in CI. Track reliability over time. Your MCP server isn’t production-ready until the cheapest model your users might connect it to can use it consistently.

🚀 MCP App Testing Framework!

Abe Wheeler — Wed, 08 Apr 2026 17:15:13 +0000

We just shipped sunpeak.ai as a standalone testing framework for MCP Apps!

If you're building MCP Apps for ChatGPT or Claude, you know the pain: deploy, open the host, start a conversation, trigger the tool, check the result. Repeat for both hosts, both themes, three display modes. That's 24 combinations per code change.

sunpeak replicates the ChatGPT and Claude runtimes locally. You write Playwright tests that call tools, render resources, and assert against the output. One test file runs against both hosts automatically.

What's included:

Unit tests (Vitest + happy-dom)
E2E tests against replicated ChatGPT and Claude runtimes
Visual regression testing with screenshot baselines
Live tests against real ChatGPT
Works with any MCP server in any language (Python, Go, TypeScript)

Add it to an existing project with one command:

pnpm add -g sunpeak && sunpeak test init

No paid host accounts. No AI credits. Runs in CI/CD.

MIT licensed and open source! https://sunpeak.ai/testing-framework/

MCP Apps are hard to test

Abe Wheeler — Wed, 25 Mar 2026 16:39:12 +0000

MCP Apps are hard to test.

They run inside ChatGPT and Claude, so every code change means deploying to a real host, burning AI credits, and waiting through non-deterministic LLM responses. If you're building for both hosts, double everything.

We built the sunpeak Inspector to fix this.

It replicates the ChatGPT and Claude MCP App runtimes on localhost. Your app renders exactly as it would inside the real hosts, with accurate display modes, themes, safe areas, and conversation chrome. One command to start:

sunpeak inspect --server URL

Works with any MCP server. Python, TypeScript, Go, whatever. No sunpeak project required.

For development: Switch between ChatGPT and Claude from the sidebar. Toggle light/dark themes, mobile/tablet/desktop widths, and display modes. Edit tool input and output live. Changes appear instantly with HMR.

For testing: The inspector doubles as the test runtime for Playwright E2E tests. Define tool states with simulation files (JSON fixtures), load them via URL, and assert against the rendered output. Test every host, theme, and display mode combination in CI/CD. No paid accounts, no API keys, no credits on your CI runners.

For coding agents: Claude Code, Codex, and Cursor can run the inspector and execute Playwright tests programmatically, so they can iterate on MCP Apps without needing a human to manually test in a real host.
sunpeak is MIT licensed and open source.

Live Testing for Claude Connectors and ChatGPT Apps

Abe Wheeler — Wed, 18 Mar 2026 18:43:24 +0000

The sunpeak simulator tests cover a lot. They replicate the ChatGPT and Claude runtimes, run display mode transitions, test themes, and validate tool invocations without any paid accounts or AI credits. For most development work, they're enough.

But simulators don't catch everything. Real ChatGPT wraps your app in a nested iframe sandbox. The MCP protocol goes through ChatGPT's actual connection layer. Resource loading happens over a real network with production builds. There's a gap between "works in the simulator" and "works in ChatGPT," and the only way to close it is to test against the real thing.

sunpeak 0.16.23 adds live testing: automated Playwright tests that run against real ChatGPT. You write the same kind of assertions you write for simulator tests, and sunpeak handles authentication, MCP server refresh, host-specific message formatting, and iframe traversal.

TL;DR: Run pnpm test:live with a tunnel active. sunpeak imports your browser session, starts the dev server, refreshes the MCP connection, and runs your tests/live/*.spec.ts files in parallel against real ChatGPT. You write assertions against the app iframe. Everything else is automated.

What Live Tests Actually Do

A live test opens a real ChatGPT session in a browser, types a message that triggers your MCP tool, waits for ChatGPT to call it, and then asserts against the rendered app inside the host's iframe.

Here's a complete live test for an albums resource:

import { test, expect } from 'sunpeak/test';

test('albums tool renders photo grid', async ({ live }) => {
  const app = await live.invoke('show-albums');

  await expect(app.getByText('Summer Slice')).toBeVisible({ timeout: 15_000 });
  await expect(app.locator('img').first()).toBeVisible();

  // Switch to dark mode without re-invoking the tool
  await live.setColorScheme('dark', app);
  await expect(app.getByText('Summer Slice')).toBeVisible();
});

live.invoke('show-albums') starts a new chat, sends /{appName} show-albums to ChatGPT, waits for the LLM response to finish streaming, waits for the app iframe to render, and returns a Playwright FrameLocator pointed at your app's content. From there, it's standard Playwright assertions.

The { timeout: 15_000 } accounts for the LLM response time. ChatGPT needs to process your message, decide to call the tool, receive the result, and render the iframe. In practice this takes 5 to 10 seconds.

Prerequisites

You need three things:

A ChatGPT account with MCP/Apps support (Plus or higher)
A tunnel tool like ngrok or Cloudflare Tunnel
Your MCP server connected in ChatGPT (Settings > Apps > Create, enter your tunnel URL with /mcp path)

You do not need to install anything extra in your sunpeak project. Live test infrastructure ships with sunpeak starting at v0.16.23. New projects scaffolded with sunpeak new include example live test specs and the Playwright config.

Running Live Tests

Open two terminals:

# Terminal 1: Start a tunnel
ngrok http 8000

# Terminal 2: Run live tests
pnpm test:live

On first run, sunpeak imports your ChatGPT session from your browser. It checks Chrome, Arc, Brave, and Edge automatically. If no valid session is found, it opens a browser window and waits for you to log in. The session is saved to tests/live/.auth/chatgpt.json and reused for 24 hours.

After authentication, sunpeak:

Starts sunpeak dev --prod-resources (production resource builds)
Navigates to ChatGPT Settings > Apps, finds your MCP server, and clicks Refresh
Runs all tests/live/*.spec.ts files fully in parallel, each in its own chat window

The MCP refresh happens once in globalSetup, before any test workers start. This means your test workers don't each individually refresh the connection, which would be slow and flaky.

The Fixture API

All live tests import from sunpeak/test:

import { test, expect } from 'sunpeak/test';

The test function provides a live fixture with:

Method	What it does
`invoke(prompt)`	Starts a new chat, sends the prompt with host-specific formatting, waits for the app iframe, returns a `FrameLocator`
`sendMessage(text)`	Sends a message in the current chat with `/{appName}` prefix
`sendRawMessage(text)`	Sends a message without any prefix
`startNewChat()`	Opens a fresh conversation
`waitForAppIframe()`	Waits for the MCP app iframe and returns a `FrameLocator`
`setColorScheme(scheme, appFrame?)`	Switches to `'light'` or `'dark'` via `page.emulateMedia()`
`page`	Raw Playwright `Page` object

Most tests only need invoke and setColorScheme. The invoke method handles the full flow: new chat, message formatting (ChatGPT requires /{appName} before your prompt), waiting for streaming to finish, waiting for the nested iframe to render, and returning a locator into your app's content.

Theme Testing Without Re-Invocation

Sending a second message to trigger a new tool call is slow and burns credits. setColorScheme avoids that by switching the browser's prefers-color-scheme via Playwright's page.emulateMedia(). ChatGPT propagates the change into the iframe, and your app re-renders with the new theme.

test('ticket card text stays readable in dark mode', async ({ live }) => {
  const app = await live.invoke('show-ticket');

  const title = app.getByText('Search results not loading on mobile');
  await expect(title).toBeVisible({ timeout: 15_000 });

  // Verify status badge and assignee are visible in light mode
  await expect(app.getByText('in progress')).toBeVisible();
  await expect(app.getByText('Sarah Chen')).toBeVisible();

  // Switch to dark mode — common bugs: text blends into background,
  // borders disappear, badge colors lose contrast
  await live.setColorScheme('dark', app);

  // Same elements should still be visible with the new theme applied
  await expect(title).toBeVisible();
  await expect(app.getByText('in progress')).toBeVisible();
  await expect(app.getByText('Sarah Chen')).toBeVisible();

  // Badge background should still be distinguishable from the card
  const badge = app.locator('span:has-text("high")');
  const badgeBg = await badge.evaluate(
    (el) => window.getComputedStyle(el).backgroundColor
  );
  expect(badgeBg).not.toBe('rgba(0, 0, 0, 0)');
});

The second argument to setColorScheme tells it to wait for the app's <html data-theme="dark"> attribute to confirm the theme propagated through the iframe boundary before your assertions run.

A Full Example

Here's a live test for a review card resource. It invokes the tool, checks the rendered content, verifies a button interaction triggers a state transition, and confirms the card re-themes correctly in dark mode:

import { test, expect } from 'sunpeak/test';

test('review card renders and handles approval flow', async ({ live }) => {
  const app = await live.invoke('review-diff');

  // Verify the card rendered with the right content
  const title = app.locator('h1').first();
  await expect(title).toBeVisible({ timeout: 15_000 });
  await expect(title).toHaveText('Refactor Authentication Module');

  // Action buttons present
  const applyButton = app.getByRole('button', { name: 'Apply Changes' });
  await expect(applyButton).toBeVisible();

  // Theme switch: card should stay readable in dark mode
  await live.setColorScheme('dark', app);
  await expect(title).toBeVisible();
  await expect(applyButton).toBeVisible();

  // Click Apply Changes — UI transitions to accepted state
  await applyButton.click();
  await expect(applyButton).not.toBeVisible({ timeout: 5_000 });
  await expect(
    app.locator('text=Applying changes...').first()
  ).toBeVisible({ timeout: 5_000 });
});

This catches real issues that simulator tests can miss: the iframe sandbox blocking a script load, a theme change not propagating through the nested iframe boundary, or a button click failing because of host-specific event handling.

The Playwright Config

The live test config is a one-liner:

// tests/live/playwright.config.ts
import { defineLiveConfig } from 'sunpeak/test/config';

export default defineLiveConfig();

This generates a full Playwright config with:

globalSetup pointing to sunpeak's auth and MCP refresh flow
headless: false because chatgpt.com blocks headless browsers
Anti-bot browser arguments and a real Chrome user agent
2-minute timeout per test (LLM responses can be slow)
1 retry per test (LLM responses are non-deterministic)
Fully parallel execution (each test gets its own chat)
Automatic dev server with --prod-resources on a dynamically allocated port

You can pass options to customize the environment:

export default defineLiveConfig({
  colorScheme: 'dark',
  viewport: { width: 1440, height: 900 },
  locale: 'fr-FR',
  timezoneId: 'Europe/Paris',
  geolocation: { latitude: 48.8566, longitude: 2.3522 },
  permissions: ['geolocation'],
});

How It Relates to Simulator Tests

Live tests don't replace simulator tests. They complement them.

	Simulator (`pnpm test:e2e`)	Live (`pnpm test:live`)
Runs against	Local simulator	Real ChatGPT
Speed	Seconds	10-30 seconds per test
Cost	Free	Requires ChatGPT Plus
CI/CD	Yes	Not recommended (needs auth)
Catches	Component logic, display modes, themes, cross-host layout	Real MCP connection, LLM tool invocation, iframe sandbox, production resource loading

Use simulator tests for development and CI/CD. Use live tests before shipping, after major changes, or when debugging issues that only reproduce in the real host.

The Testing Pyramid for Claude Connectors

A Claude Connector built with sunpeak now has three test tiers:

Unit tests (pnpm test): Vitest, jsdom, fast, test component logic in isolation
Simulator e2e tests (pnpm test:e2e): Playwright against the local ChatGPT and Claude simulator, test display modes and themes, runs in CI/CD
Live tests (pnpm test:live): Playwright against real ChatGPT (with Claude coming soon), test real MCP protocol behavior and iframe rendering

Each tier catches different classes of bugs. Unit tests catch logic errors. Simulator tests catch rendering and layout issues across hosts and display modes. Live tests catch protocol and sandbox issues that only show up in the real host environment.

All three are pre-configured when you run sunpeak new. You don't need to set up Vitest, Playwright, or any test infrastructure yourself.

Host-Agnostic Architecture

The live test infrastructure is designed to support multiple hosts. The live fixture resolves the correct host page object based on the Playwright project name. All host-specific DOM interaction (selectors, login flow, settings navigation, iframe nesting) lives in per-host page objects that sunpeak maintains.

Your test code is host-agnostic:

import { test, expect } from 'sunpeak/test';

test('my resource renders', async ({ live }) => {
  const app = await live.invoke('show me something');
  await expect(app.locator('h1')).toBeVisible();
});

This same test will run against any host that sunpeak supports. Today that's ChatGPT. When Claude live testing ships, add it with one line:

// tests/live/playwright.config.ts
export default defineLiveConfig({ hosts: ['chatgpt', 'claude'] });

No changes to your test files.

Getting Started

If you have an existing sunpeak project, update to v0.16.23 or later:

pnpm add sunpeak@latest && sunpeak upgrade

Create tests/live/playwright.config.ts:

import { defineLiveConfig } from 'sunpeak/test/config';
export default defineLiveConfig();

Add the test script to package.json:

{
  "scripts": {
    "test:live": "playwright test --config tests/live/playwright.config.ts"
  }
}

Write your first live test in tests/live/your-resource.spec.ts:

import { test, expect } from 'sunpeak/test';

test('my tool renders correctly in ChatGPT', async ({ live }) => {
  const app = await live.invoke('your prompt here');
  await expect(app.locator('your-selector')).toBeVisible({ timeout: 15_000 });
});

Start a tunnel, run pnpm test:live, and watch Playwright drive a real ChatGPT session.

New projects created with sunpeak new include all of this out of the box, with example live tests for every starter resource.

Claude Simulator for MCP Apps: Test Claude Apps Locally with sunpeak

Abe Wheeler — Mon, 02 Mar 2026 15:15:24 +0000

TL;DR: sunpeak v0.15 adds a local Claude simulator. Run sunpeak dev, pick Claude from the Host dropdown (or ?host=claude URL Param), and test your MCP App in both Claude and ChatGPT from one dev server.

Until now, sunpeak's local simulator only replicated the ChatGPT runtime. If you wanted to test how your MCP App looked in Claude, you had to deploy it and connect it manually. That's fixed.

sunpeak v0.15 ships with first-class Claude support. The old ChatGPTSimulator is now just Simulator, and both Claude and ChatGPT are registered as host shells out of the box. Switch between them with a dropdown, a URL param, or a prop.

What Changed

The simulator is now multi-host. Instead of a single ChatGPT-specific component, sunpeak uses a pluggable host shell system. Each host registers its own conversation chrome, color palette, and theme behavior. The Simulator component renders whichever host you select.

Two hosts ship by default:

ChatGPT uses the familiar gray/white palette with the ChatGPT conversation layout.
Claude uses a warm beige/cream palette matching claude.ai, with Claude's conversation chrome.

Both implement the core MCP App protocol, but each host adds its own extras. ChatGPT supports host-specific features like file uploads and downloads on top of the standard. Claude doesn't have additional host APIs today, though sunpeak's Claude host shell does handle Claude's rendering quirks. If Claude adds host-specific capabilities in the future, they'll be built into this shell. Your resource component renders in both, wrapped in each host's chat UI, so you see exactly what your users will see.

How to Use It

If you already have a sunpeak project, update to v0.15 and migrate your CSS classes:

sunpeak upgrade

Then run the dev server:

sunpeak dev

Open localhost:3000. You will see a Host dropdown in the simulator sidebar. Select Claude to test your app in the Claude runtime. Select ChatGPT to switch back.

If you are starting fresh:

pnpm add -g sunpeak
sunpeak new
cd my-app && sunpeak dev

The scaffolded project uses the new Simulator component by default. Both hosts are available from the first run.

Host Selection

Three ways to pick a host:

Sidebar dropdown. The Host control appears in the sidebar when multiple hosts are registered. Click it to switch at runtime.

URL parameter. Add ?host=claude or ?host=chatgpt to the simulator URL. This is useful for bookmarking a specific host, linking teammates to a particular test configuration, or testing certain rendering states automatically.

defaultHost prop. Set the initial host in code:

import { Simulator } from 'sunpeak/simulator';

<Simulator
  simulations={simulations}
  defaultHost="claude"
/>

The default is chatgpt if you don't specify one.

Migrating from ChatGPTSimulator

If your project uses the old ChatGPTSimulator from sunpeak/chatgpt, it still work as an alias to the new simulator. No migration is required, but the alias will be removed in the near future.

The change is small. In your dev entry point, replace:

// Before
import { ChatGPTSimulator } from 'sunpeak/chatgpt';

<ChatGPTSimulator simulations={simulations} />

with:

// After
import { Simulator } from 'sunpeak/simulator';

<Simulator simulations={simulations} />

Same simulations, same resource components, same test suite. The Simulator just adds the host dropdown and Claude's rendering behavior.

What Your App Looks Like in Claude

The Claude host shell wraps your resource component in Claude's conversation UI. The background uses Claude's warm beige and grey instead of ChatGPT's white and dark grey. User messages appear in Claude's bubble style. The toolbar and display mode controls (inline, fullscreen, picture-in-picture) work the same way.

The core data flow is shared across hosts. useToolData receives the tool output. useAppState syncs state back to the host. SafeArea handles safe rendering boundaries. These work the same in both Claude and ChatGPT.

Where hosts differ is in extras. ChatGPT supports host-specific features like file uploads and downloads that go beyond the MCP App standard. Claude has its own rendering quirks that sunpeak's host shell accounts for. If Claude adds host-specific APIs later, sunpeak will surface them through the same shell system.

The simulator lets you catch these differences locally instead of deploying to find out.

Extensible Host System

The host shell registry is open. If a new major MCP App host appears, sunpeak can add support without changing the Simulator component or your resource code. Each host registers itself with an id, a label, a conversation component, a theme function, and style variables. The simulator picks up all registered hosts automatically.

For now, Claude and ChatGPT cover the two largest MCP App hosts.

Getting Started

pnpm add -g sunpeak
sunpeak new
cd my-app && sunpeak dev

Open localhost:3000, select Claude from the Host dropdown, and start building.

How to Build a Claude App covers architecture and code patterns for Claude.
ChatGPT App Tutorial walks through building a resource from scratch (same steps work for Claude).
Building One MCP App for ChatGPT and Claude covers the cross-platform story.
Testing guide covers Vitest and Playwright setup.
sunpeak documentation has the quickstart and full API reference.

Build once with sunpeak, test locally in both Claude and ChatGPT, and ship to every MCP App host.

sunpeak is all-in on MCP Apps

Abe Wheeler — Wed, 11 Feb 2026 17:18:22 +0000

MCP Apps now run in ChatGPT, Claude, Goose, and VS Code. That happened fast. Claude announced MCP App support on January 26, and ChatGPT followed on February 4. Two weeks, two major hosts, one standard.

TL;DR: sunpeak's APIs are built around the MCP App standard. ChatGPT and Claude-specific features are layered on top as optional imports. Write your app once, run it everywhere—even localhost.

Why MCP-App-First

When ChatGPT Apps launched in October 2025, they had their own proprietary SDK. Building for ChatGPT meant building only for ChatGPT.

That changed when OpenAI contributed to and aligned on MCP Apps as the open standard. The rendering model, the iframe sandbox, the UI functionality — all of it became portable. And as of February 2026, the major hosts actually implemented it.

sunpeak followed the same trajectory. We started as a ChatGPT App framework because ChatGPT was the only major host supporting embedded UIs. Now we're an MCP App framework, because the standard is real and the host list is growing.

What that means in practice: sunpeak's core APIs target the MCP App interface, not any single host. At the same time, sunpeak layers in the major host-specific functionality developers need to seamlessly support differentiated platforms (think React Native).

How It Works

sunpeak separates standard MCP App APIs from host-specific ones at the import level.

Core APIs come from the top-level sunpeak import. These work everywhere:

import { useToolData, useHostContext, useDisplayMode, AppProvider } from 'sunpeak';
import type { ResourceConfig } from 'sunpeak';

export const resource: ResourceConfig = {
  name: 'dashboard',
  description: 'Show analytics dashboard',
};

export function DashboardResource() {
  const { output } = useToolData();
  const context = useHostContext();
  const displayMode = useDisplayMode();

  return <div>{/* Your UI — runs in ChatGPT, Claude, Goose, VS Code */}</div>;
}

Host-specific APIs come from subpath imports. Right now that's sunpeak/chatgpt for ChatGPT-specific tooling:

import { ChatGPTSimulator, buildDevSimulations } from 'sunpeak/chatgpt';

The ChatGPT simulator, dev simulation builder, and any ChatGPT-only runtime features live here. They're first-class — not afterthoughts or community plugins — but they don't pollute your app code. Your resource components stay portable.

What Changed, What Didn't

If you're already using sunpeak, you'll notice v0.13 changes many APIs to be based on MCP App abstractions and nomenclature.
Fortunately, a lot of Apps SDK knowledge is easily portable to the MCP App interface.
Refer to the release notes for more specific migration instructions,
and refer to the sunpeak docs for a complete overview of sunpeak and MCP Apps.

With these changes, your app renders in Claude (and others) today. The sunpeak dev simulator at localhost:6767 replicates the MCP App runtime that all hosts implement, so what works locally works in production across hosts.

The Host Landscape

Here's where MCP Apps run today:

ChatGPT — OpenAI contributed elements of the original ChatGPT Apps protocol to MCP and now supports the open standard alongside their existing SDK.
Claude — Anthropic's web and desktop clients render MCP Apps natively.
Goose — Block's open-source AI agent supports MCP Apps.
VS Code Insiders — Microsoft's editor renders MCP Apps in the chat sidebar.

More hosts will follow. The MCP App standard is under the Linux Foundation now, and the spec is actively developed at modelcontextprotocol/ext-apps.

Platform-Specific Features Are First-Class

MCP-App-first doesn't mean lowest-common-denominator. ChatGPT has features that Claude doesn't, and vice versa. sunpeak treats these as first-class extensions, not hacks.

For ChatGPT, that means full access to OpenAI's apps-sdk-ui component library, the ChatGPT simulator for local development, and any ChatGPT-specific runtime APIs. These are maintained alongside the core framework, tested in CI, and documented.

As Claude and other hosts ship their own platform-specific features, sunpeak will add corresponding subpath imports. The pattern scales: core stays portable, extensions stay organized.

Get Started

sunpeak is open source and free.

pnpm add -g sunpeak && sunpeak new

Your app works across ChatGPT, Claude, and every other MCP App host from the first line of code.

Documentation: guides, API reference, and tutorials
GitHub: source code and issue tracker
MCP App Framework: overview of sunpeak's capabilities