FreeCAD-in-the-browser — session archive
The complete Claude Code transcripts that produced the port
This is the raw material behind the writeup: every session, every
sub-agent, every workflow that Fable ran to port FreeCAD to WebAssembly. It is published so the
claim in the post — that the human involvement was a few dozen high-level prompts and nothing more —
is checkable. Read the prompts below, then open any session and scroll the actual work.
By the numbers
| Sessions | 3 (Claude Code split the effort as context filled) |
| Span | 2026-07-03 → 2026-07-07 (~4 days) |
| Human prompts, total | 48 — listed in full below |
| Multi-agent workflows | 15 |
| Sub-agent invocations | 159 (14 direct + 145 inside workflows) |
| Archive size (raw JSONL) | 177 files · ~115 MB uncompressed |
All Magik’s prompts — no other meaningful human involvement beyond these
Every message the human sent, across all three sessions, in order. Giant pastes
(console logs, profiler dumps) are marked [like this];
everything else is verbatim. Two are from a short parallel session opened in ./freecad-port.
The steering also included three /goal resets, shown after the list.
- Current repo contains a fully functional port of LibreCAD to wasm. deploy/index.html contains a blogpost about the effort, there are also some plans etc about the effort. Now we're moving on to the big guns. Asses feasibilty of porting https://github.com/freecad/freecad. Assume this is very ambitious and we will have to do some webgl/webgpu work at least.
- Clone freecad, write down detailed research and plan documents, prepare a staged execution plan
- continue with the goal, working webgl viewport is the point of this project so prioritise that, then continue with remaining stages
- 1. Yeah we need to go to JSPI, same as we did in the LibreCad project (needed newer qt/etc too?). 2. Coin - can we think of the most viable option? Rewriting so that those calls aren't used? Catching and emulating those features? Using different opengl->web(gpu/gl) translation layer, even rolling our own with just the required bits? Plan for now, but assume we will be continuing this effort
- Full rebuild is fine, we're on a massive monster machine so it will be quick. Resume the effort and push to completion
- Address remaining issues, especially the viewport
- Btw we now have a working openscad ./openscad port which has a functional OGL 3d viewport too, look at what was done there, then continue our efforts
- Create a rough deployment (freecad/deploy) like we had for LibreCad and OpenScad so that I can eval the progress myself
- Interesting, I see what you see, but never see the actual object rendering, BUT when going through context menu->face->sth I see the face, @2026-07-04-205009_2396x2075_scrot.png, when just moving mouse around the canvas I see occasional green line highlights, so evidently there is some rendering.
- Similar to before, still see faces/outlines from context menu, but no longer see lines/outlines on just mouse over. Console: We have lots of errors, the readPixels one may be interesting? Other than that also pretty long promise chains: [+ ~3,800 lines of WebGL console errors & wasm stack traces pasted]
- It works and renters! Camera feels correct too. On drag I'm seeing all-white screen with gray selection which I assume is just selection which doesn't do anything presumably because we don't have the rest of the CAD running yet, but overall really good progress! Not much new in the console, just seeing the enum stuff still
- Continue until all steps are implemented and we have desktop feature parity
- pretty sure the probe is stuck
- It shouldn't take that long to start, for me it's maaybe 10s, maybe 20 tops
- Quick Q: can we rewrite / modify / adapt PySide/shiboken such that it becomes wasm-compatible? Also list out All modules that need porting, missing modules, then other minor-but-major missing bits - high level gaps
- Commit where we are now; Start a swarm of subagents to tackle all of those in parallel at the same time, at least from code perspective
- Sounds like our next focus is PySide/shiboken then - this is the major thing to derisk and just do -- set up environment to work on that, use a swarm of agents to define needed (and relevant to FreeCAD) scope that we need to port, and execute the port with a huge workflow/agent swarm to attack the problem in the most efficient way
- Continue driving the whole way, M1->M3
- Sandbox crashed for whatever reason (running in a flimsy docker sandbox..), resume the session
- [parallel ./freecad-port session] Review progress in ./; Research sessions in .claude which previously worked on this, the last most progressed session died midway in advanced stages of porting components, we have rendering etc pretty far advanced, but you're running in a somewhat flimsy docker SBX sandbox so... Research where we are carefully, note I tried to resume those sessions but claude-code couldn't see the correct one correctly, so not even sure if the real latest is there, and also the session files probably got touched so timestamps on them may or may not be correct. Use subagents to figure out what's what
- [parallel ./freecad-port session] Is there a claude command to resume that session directly?
- Needed to restart Claude Code again to enable skip-permissions enabling you to work faster
- note that ./ is in host btrfs, that is very unlikely to be actually corrupted. Maybe put everything relevant from this workspace that's not in ./ or ./freecad-port to ./freecad-artifacts and I'll transplant that + .claude to a real VM for you to do the work from (this session just moved)
- Anything else beyond .claude that's needed that I need to move?
- progress? Somehow artifacts got smaller — [+ pasted du output showing ../freecad-artifacts shrinking 4.5G → 3.6G]
- Kill rm, move -artifacts to -artifacts.bad and redo clean copy
- Welcome to the other side! Asses the current environment, you are currently in a much lighter mount namespace-backed sandbox, ./ and few other locations are rw, try to keep the current dir as the only workspace; If you need system packages let me know (ideally now in bulk), for python stuff use venv. Host is Arch now
- I can give you bind mounts, just give me a list in format '--bind /some/place=/home/magik6k/... --bind=..'
- Done, lets go!
- installed
- continue, switched to ultracode
- Research and propose a concrete roadmap to full desktop parity
- Plan to attack multiple milestones all in parallel in one massive super-workflow, this should be the biggest pust in the session yet, try to go from where we stand now to as far as we can feasibly get in browsers in as much 'one go' as is possible. The workflow will need to be carefully planned multi-step multi-agent-swarm wonder of engineering itself.
- Keep going through next stages, as previously do a workflow researching what's in play. We also have some gaps in the UI, maybe missing some Qt assets/setup — see @…scrot.png — context menus are very unstyled, no ui elements do anything on mouse-over, right tasks panel has no background, font is weirdly big etc. Also could try to improve perf a little bit, would get better profile trace but there are no wasm debug symbols it seems: [+ profile trace pasted]
- Quick Q: Are we using asyncify or JSPI?
- Good news: UI looks great! Bad news: some rendered 3d components vanish and show up when hovered over: ./[Image #1] - may be the optimizations -- JSPI probably would be quite a bit faster, might be worth a try; Let's fix those two before moving to next steps
- Bottom-up perf in frame render doesn't do much sense to me, but this is what the profiler says — [+ profile table: ffVertex / bufferData / Minor GC / texSubImage2D hot spots]
- Implement ff_setup_and_draw, and in parallel jump on the remaining parity work
- Go to remaining steps, everything 2-4, then we will asses if anything more is doable
- Debug the issue down to provably true root cause
- Try to implement the fix
- Fix the remaining BIM/CAM functionality, we're close to having it working now, then push for final production polish
- What would it take to fix those: [+ console errors — Cannot find icon: MassPropertiesIcon; No module named 'Tux_rc'; No module named 'urllib.request'; and missing workbench SVG icons for Assembly / BIM / CAM / Draft / Mesh / PartDesign / Points / Spreadsheet / Surface…]
- Do Tux/MassProperties
- Seems FEM works correctly with the example showing correct deflection; In FEM example double clicking on material crashes: [memory access out of bounds in QWidgetWindow::focusObject() → PythonConsole::printPrompt] — in other example getting missing font/resource errors: [TechDraw failed to load font osifont-lgpl3fe.ttf and 3 more] — Also on the setup screen dark mode selection doesn't do anything. Any resources we should think about bundling / hot loading?
- Think if we can win some rendering performance, bottom-up profile of a few seconds [+ profile table] — Rendering is at 3-4 fps right now
- Look at how Librecad (./deploy) and openscad (./openscad/deploy) were deployed, especially the project/intro post. Structure it like that, improve the app loades (we now load quite a bit more than just wasm on startup, the loader should get the boldness of this project across, then write a detailed technical post like the openscad one, linking to openscad and librecad on https://magik.net/; This will also be deployed there; Unlike those two posts go into really deep detail on all changes you made, every fix and direction looked at and done in sequence; Refer to the Librecad-in-the-browser post on HN that gave me the idea to do this project - https://news.ycombinator.com/item?id=48755075); Also put all patches/artifacts into deps or sth like that dir of freecad such that we'll be able to publish it on github (repo will be magik6k/freecad-web)
- Expand on my involvment and on how the session went. There is claude-code repo backup in ./claude-bak6/projects/... Match which sessions are related to this freecad project (there are multiple probably due to just being huge and CC breaking it into multiple). Extract ALL my prompts and put them in one paragraph one by one as 'All Magiks prompts - No other meaningful human involvement beyond those'. Also package the session archive to be broweseable and downloadable (just the freecad sessions with workflows subagents etc; Sanitize any secrets - though there shouldn't be any pretty sure)
The goal, as it was re-set over those four days:
- /goal Working fully functional FreeCAD Web port
- /goal Full review of work so far, Working 3D viewport, Reasonable feature parity with desktop
- /goal Full desktop feature parity
The sessions
Feasibility & first port · 18e25685
The kickoff: assess whether FreeCAD can go to wasm at all, clone it, stand up the toolchain, and fight the 3D viewport to first pixels.
Jul 3 – Jul 50 subagents1 workflows46 workflow agents
Main port (continued) · 17f09f89
The long haul: PySide6, the workspace relocation, the parity super-workflow, FEM Stage 1 & 2, the render-perf pass, and the deploy.
Jul 4 – Jul 712 subagents14 workflows99 workflow agents
Side session (freecad-port) · 832fa851
A short parallel session opened in ./freecad-port to work out how to resume the main effort after a sandbox hiccup.
Jul 52 subagents0 workflows0 workflow agents
Download
The full, unabridged archive — all three top-level transcripts plus all 174 sub-agent and
workflow-agent logs, as newline-delimited JSON:
⤓ freecad-web-sessions.tar.gz · 48 MB
Sanitized before packaging: credential-shaped strings (API keys, tokens, private-key
blocks) and the author’s email are scrubbed. A scan turned up none of the former — the port
never handled secrets — but the pass runs regardless. The browseable pages above truncate long tool
outputs and thinking blocks for readability; the tarball is complete.
Part of FreeCAD in your browser ·
the app · source.
Written and assembled by Fable.