Software engineering / AI & security / 2026
Apertide
An independent Code-OSS fork connecting security findings, source review, optional local AI and recorded checks in one editor.
- My role
- Fork development, workflow design and native packaging
- Stage
- Local alpha · Code-OSS fork
- Built with
- TypeScript · Code-OSS · Electron · SARIF · Ollama · Node.js
01 / Context
The problem
Scanner reports, source files, suggested fixes and test output often sit in separate tools. A useful review workspace needs to connect them while preserving report provenance and distinguishing an inspected finding, a proposed edit and a real check result.
02 / Ownership
My contribution
I developed the Apertide Workbench extension and product identity on top of Microsoft's Code-OSS editor. The latest 0.2.0 revision replaces a landing-style Desk with compact workflow navigation, a file-first findings queue, a separate source inspector and root project inspection. My work includes SARIF import and triage, explicit-context Ollama streaming, single-file proposals with native diff review, fixed local checks, persistent evidence journals, a read-only GitHub adapter, Graphite and Paper themes, and an Apple Silicon application build. Editing, debugging, Git and terminal foundations come from Code-OSS.
03 / Reasoning
The decisions behind it
Make review useful without a model
Project inspection lists actual root files and declared npm scripts without executing them. Findings preserve tool, rule and location provenance; nearby source preview, triage, checks and evidence export work independently of inference.
Keep context and application explicit
Only captured source and the current mode conversation are sent to local Ollama. The model cannot execute tools. Full-file proposals require native diff review and explicit application; source hashes are checked before and after confirmation. Applied edits remain unsaved and undoable.
Record checks as evidence
Fixed JavaScript syntax and workspace npm-test profiles retain real output, exit status and timing, with cancellation and a 60-second limit. Development and Assessment keep separate conversations and journals. A reviewed finding or passing test does not establish vulnerability remediation.
Build on an existing editor responsibly
The fork retains Code-OSS licensing and third-party notices while using independent branding and a bundled extension. GitHub reads use existing CLI authentication. Assessment mode organises a workflow; it does not change host permissions or authorise remote testing.
Workflow / Getting started
How to use it
Open a local workspace
Launch Apertide, open a trusted project folder and choose Apertide: Open Desk from the command palette. Use Project → Inspect root files to see recognised manifests and declared npm scripts.
Review existing findings
Switch to Assessment and import a SARIF 2.1.0 report generated by an external tool. Select a finding, preview or open its source, and record Open, Reviewed or Dismissed status. Imported locations must resolve to existing files inside the workspace.
Use local assistance when helpful
Check the Ollama service, choose an installed model and explicitly capture source or a finding. Inspect the context preview before asking. A proposal needs complete-file context; open its diff, apply deliberately and save the edit.
Check and hand over
Use Checks & evidence to check captured JavaScript or run the workspace's npm test, inspect the recorded result and export JSON evidence. Repository can refresh origin, branch, changes and up to ten open PRs through Git and an authenticated GitHub CLI.
04 / In practice
A closer look
05 / Evidence
Verification & boundaries
Reviewed against local commit e8dc42c7925 on 5 October 2026. All 13 targeted unit tests passed, and the installed application's bundled extension passed fresh-process switch, restore and isolated-workspace integration phases. A fresh non-inference packaged UI run passed report review, project inspection, repository reads, themes and native terminal output without renderer exceptions. The recorded 4 October workflow additionally exercised Gemma 3 12B explanation and proposal generation, native diff/application/save and a real fixture npm test. Screenshots use synthetic fixtures; they establish those exercised paths.
What this does and does not establish
A local Apple Silicon alpha without Developer ID signing or notarisation. The custom implementation remains on a local branch; the public repository currently exposes the upstream fork. Managed scanners, remote target enforcement, scanner baselines and verified-resolution tracking remain planned. Fixed checks and the native terminal execute with host permissions. The journal is not tamper-proof, model output is unverified, and the full upstream suite and a security audit have not been completed. Local inference does not establish that every upstream or third-party network path is local-only.
06 / Looking ahead
What comes next
Complete one real report-to-fix review with revision-linked evidence and scanner baseline comparison, then add one managed scanner adapter. Prepare the custom source, extension distribution review and signed packages for a public release.