osFoundry / Platform
Native runtime
On desktop, your app can run as a native process with filesystem and shell access — gated by a permission dialog.
What it is
Native runtime lets an app inside osFoundry run as a real native process on your machine instead of being confined to a sandboxed web view. On desktop, that means the app can read and write files on your local filesystem and invoke shell commands directly, the same access a normal desktop program has. This is the difference between an app that can only talk to remote APIs and one that can actually touch the files you already have, run a build, call a local binary, or process a folder of data without uploading it anywhere.
Because that access is real, it is gated. The first time an app wants to reach the filesystem or the shell, osFoundry surfaces a permission dialog and the app does nothing until you approve. Permission is an explicit, human decision, not a default the app grants itself. This keeps the native runtime honest with osFoundry's local-first posture: your data can stay on your device, the app operates against local paths and processes rather than a cloud round-trip, and you see and consent to what it is allowed to do.
Inside osFoundry, the native runtime sits alongside the rest of the workspace — the same place you run chat and agents, write code, and keep knowledge and data. An app you build or install can move from a purely networked tool to one that participates in your local environment, while the BYOK model means the AI parts of that app run on your own keys with no reseller markup. The runtime is a desktop capability: it depends on being on your machine, which is exactly what makes filesystem and shell access possible and safe to reason about.
Key capabilities
- Run an app as a native desktop process, not a sandboxed web view, so it can act on your real machine
- Read and write local files directly, letting apps work against folders and data already on your device
- Invoke shell commands and local binaries from inside the app, for builds, scripts, and system tasks
- Every filesystem and shell request is gated by an explicit permission dialog you approve before anything runs
- Local-first by design: work stays on your device instead of a cloud round-trip, and AI runs on your own BYOK keys
Use cases
- Developer: build an app that runs a local test suite or build script via shell and shows the results in the workspace
- Data analyst: point an app at a folder of CSVs on disk and process them in place, without uploading the files anywhere
- Privacy-conscious user: run a tool that reads local documents natively, approving filesystem access once through the permission dialog
Frequently asked questions
Can an osFoundry app really access my filesystem and shell?
Yes, on desktop an app can run as a native process with real filesystem and shell access. It is not a browser sandbox. That access is gated: the app must get your approval through a permission dialog before it can read files or run commands.
How is the native runtime kept safe if it can run shell commands?
Access is not automatic. When an app wants the filesystem or shell, osFoundry shows a permission dialog and the app stays blocked until you approve. You decide what it is allowed to do, which fits the local-first model where your data can stay on your device.
Is native runtime available on the web version?
It is a desktop capability. Running as a native process with filesystem and shell access depends on being on your own machine, which is what makes that access possible in the first place. Web contexts do not grant that kind of local reach.