Claude Code should be able to work inside the user's open editor tab.
This first stage connects the two and lets the agent look: what the
user sees and a picture of it. Changing the project comes in stage 2.
- An agent token per account opens only /mcp, no API route. The
dialog "Agent tokens..." in the account menu creates it once, shows
the ready "claude mcp add" line and revokes it. The server keeps
only its sha256 (api/lib/AgentTokens.php).
- Wrong tokens count into the sign-in brake from #427. Changing the
password, renaming or deleting an account ends its tokens.
- The relay (tools/mcp/) is a small Node service without packages,
WebSocket server included. It runs in the container feuerwerk-mcp
because PHP-FPM cannot hold connections. Whether a token or a tab
ticket is valid is still decided by the PHP API, through two routes
that answer only with the relay key.
- The tab joins over WebSocket on the same origin with the normal
session, an Origin check and a one-time ticket. It connects only
after "Agent" is switched on in the account menu. One tab per
account is active, a new one takes over. Guests get nothing.
- Tools: get_view (project, tab, document, selection with names,
camera, play state, open dialog) and screenshot. The resource
feuerwerk://view can be subscribed. Claude Code does not act on
that reliably, so a changed view is also noted on the next answer.
- A badge next to the account menu shows the connected agents. It
counts only agents with an open stream or a request in the last
two minutes.
- CI starts the relay in front of php -S (tools/ci/serve.sh), and
e2e 71 runs the whole path in the browser.
Found on the live test: the badge showed four agents because old
sessions of revoked tokens were still counted.
Tests:
- Gate on atx: 316 files, 4888 tests
- relay protocol test with fake API and fake tabs: 23/23
- get_view, tools, socketUrl: 16/16
- PHP agents 29, rights 103 checks
- e2e 71 on atx 10/10, against the live site 10/10, no CSP violation
- real Claude Code against the live site: get_view answered
- ZAP against /mcp: nothing at High or Medium
- every new check fails when the guard it covers is taken out (6)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The subdomain proxies to the same folder, but the build had the path
/feuerwerk/ baked in. On feuerwerk.nockal.com the page loaded its
assets, the API and the data URLs from /feuerwerk/... and got 404. The
session cookie had Path=/feuerwerk/, so the browser would never have
sent it to /api/ there either.
- site.ts takes the base path from the folder of the open page:
/feuerwerk/ on nockal.com, / on the subdomain. Release links point at
the address you are working on.
- vite.config.ts builds with a relative base. The copy plugin rewrites
the pages to ./dist/assets/ and stops the build if it finds nothing
to rewrite. The dev server now runs at http://localhost:5175/.
- Auth.php sets the cookie without a Path, so it belongs to the API
folder the browser sees. Sign-in and sign-out also clear the old
/feuerwerk/ cookie, otherwise it would keep signing in after a
logout. Existing sessions stay valid.
- README: the new dev server address.
Tests:
- curl on both addresses: pages, JS, CSS and API 200
- sign-in, session, sign-out on both addresses
- e2e 70 against both addresses: 13/13 each, no CSP violation
- tsc, lint, prettier clean, site and releases tests 14/14
- PHP tests 7 of 8 files green, videos.test.php fails only because
the web-php-fpm container has no ffmpeg
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The editor gets a name of its own that fits beside Brandmauer,
Glutspeicher and Feuerwehr. This is stage 1, 2 and 4 of #422: the
name, the URL and the stored state in the browser. Repository, CI
runners, containers and the GAME_MAKER_* variables follow in stage 3.
- All paths come from SITE_PATH in src/core/site.ts: the API endpoint,
the data folders, the play page and the base in vite.config.ts. A
later move is one line instead of fifteen.
- The window title, the sign-in screen, the playground and the README
say Feuerwerk. The package, __feuerwerkPlay, the take worklet and the
writing app in Ogg and Matroska follow.
- The session cookie is now feuerwerk_session, so everyone signs in
once more.
- localStorage keys are now feuerwerk.*. moveOldStoredKeys copies the
old game-maker.* keys over on the first start, so settings, panel
sizes and save games survive.
- tools/ci/serve.sh serves the build under /feuerwerk/. The variable
GAME_MAKER_BASE_URL keeps its name until stage 3.
Outside the repository, nockal.com/feuerwerk/ is a second symlink to
the same tree. nginx sends the bare /game-maker/ folder there with a
301. Everything else under /game-maker/ is still served directly, so
shared play links and the API keep working.
Finding: when nginx redirects a path without a trailing slash or with
a query, the Brandmauer answers with its own 307 to the same URL plus
a slash, placed after the query. A play link would lose its token that
way, which is why only the bare folder is redirected.
Tests:
- Gate on melektaus-atx: CHECK EXIT 0, 307 files, 4756 tests
(4 new in site.test.ts).
- Counter-check: when the migration misses the old prefix, 3 of the
4 new tests fail.
- e2e 60 under /feuerwerk/: ALL PASSED, 20 checks.
- From outside: /feuerwerk/ 200, /game-maker/ 301, an old play
link 200.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
adminandClaude Opus 5.5