OpenScreen v1.10.0 covers capture, editing, and export
OpenScreen v1.10.0 records a display or window with microphone, system audio, webcam, and cursor data. Its editor adds automatic or manual zooms, click effects, crop and trim controls, speed regions, backgrounds, motion blur, annotations, and captions. Export produces MP4 or GIF through Metal on macOS, D3D11 on Windows, or Vulkan on Linux, with a CPU fallback. That is a serious product-demo toolset rather than a bare screen recorder.
The 49.8 MB checkout also ships a headless CLI. Scripts can list sources, record, inspect or pack a project, add captions, and export through the same pipeline as the desktop editor. Machine-readable NDJSON makes it useful in CI and coding-agent workflows. The .openscreen project is JSON, so a tool can add trims, zooms, and annotations directly. The README warns that this format and the CLI can still change, which matters if automation will outlive one release.
Seven provider choices make AI editing optional
OpenScreen's editing assistant accepts plain-language requests for cuts, zooms, speed changes, annotations, and camera framing. The README lists 7 provider routes: Claude, OpenAI, Gemini, Mistral, OpenRouter, MiniMax, and OpenAI-compatible endpoints. Users bring their own key, and the feature starts disabled. Teams can therefore use the recorder, editor, and export path without sending editing instructions to a model provider.
The 954 MB installed dependency tree includes far more than a React interface. Electron handles the desktop shell, native helpers capture each platform, Rust code composes frames, and FFmpeg plus ONNX components support media work. Local speech recognition uses Whisper and downloads its model on first use. That architecture explains the feature reach and the build burden. Developers changing capture or export need the matching operating-system toolchain, not only Node and npm.
What happened when we ran it
Our sandbox installed 766 npm packages in 33 seconds, leaving 954 MB on disk. The default build ran for 46 seconds and exited with code 1. Its final stack frames came from checkNativePayload, checkLinuxNativePayload, electron-builder's beforePack event, and the Linux packager. The supplied log tail does not name the offending payload, so a claim about which binary or library caused the stop would be guesswork.
Vitest completed in 108 seconds: 2,687 tests passed, 0 failed, and 1 was skipped out of 2,688. That result gives the application logic substantial coverage even though packaging failed. Npm audit reported 38 known vulnerabilities across the installed tree, split into 1 critical, 7 high, 28 moderate, and 2 low. Before distributing a custom build, inspect whether each advisory reaches shipped code and whether dependency updates preserve the native integrations.
Platform support comes with specific permission costs
The README sets Windows 1903, macOS 13, and 8 GB of RAM as minimums, with newer hardware and 16 GB recommended. macOS requires Screen Recording and Accessibility access, and may ask again for recording permission on later system releases. Windows users get the checked signing path through the Microsoft Store. The standalone .exe is unsigned, so SmartScreen reports an unknown publisher. That distinction should be written into internal install instructions.
Across 1,278 repository files, Linux receives the most conditional path. Native recording expects PipeWire and an xdg-desktop-portal backend. A browser capture fallback remains available with fewer capabilities. Wayland exposes cursor position and shape through the portal, while click effects require reading the left button through evdev and membership in the input group. Older PulseAudio-only setups may miss system audio even when microphone capture works.
September activity is fast enough to demand release checks
GitHub showed 2,470 stars and 68 open issues and pull requests when fetched. The last push was September 7, 2026, and the latest tagged release was v1.10.0 from August 24, 2026. The repository contains 21 CI workflow files and an active stream of fixes around capture, packaging, transcripts, editor behavior, and Nix support. The combined open count includes pull requests, so it should not be read as 68 confirmed bugs.
Our scan found 21 workflows, a tests directory, and no Dockerfile. The missing container recipe is unsurprising for a hardware-facing desktop app, but it removes one portable source-build reference. The release route is much friendlier: signed and notarized macOS builds, a signed Microsoft Store package, and Linux packages for Debian, Fedora, Arch, AppImage, and Nix. Users who only need the application should start there instead of reproducing the native toolchain.
Open capture reports justify a disposable first recording
Issue 621 describes a macOS 1.9.6 recording where the output stopped while capture and the on-screen timer continued. The report is unusually detailed and says the event could not be reproduced on demand. Issue 615 describes an Arch Linux GNOME Wayland recording with invalid H.264 access units that external FFmpeg could re-encode, while OpenScreen's own preview failed. Neither report proves that every v1.10.0 installation has the same fault. Both identify failure modes worth testing.
commit 7d355e7 passed 2,687 tests in our sandbox, which makes OpenScreen easier to trust than its active-development warning alone would suggest. The failed 46-second package build and 38 audit findings still prevent a clean source verdict. Use the official signed package where possible, record a short sample with the intended screen, audio, webcam, and GPU path, stop it, preview it, and export it before committing an unreproducible session.