osFoundry / Platform
Runtime nativo
En escritorio, tu app puede ejecutarse como proceso nativo con acceso al sistema de archivos y al shell, controlado por un diálogo de permisos.
Qué es
El runtime nativo permite que una app dentro de osFoundry se ejecute como un proceso nativo real en tu máquina, en lugar de quedar confinada a una vista web en un entorno aislado. En el escritorio, eso significa que la app puede leer y escribir archivos en tu sistema de archivos local e invocar comandos de shell directamente, el mismo acceso que tiene un programa de escritorio normal. Esta es la diferencia entre una app que solo puede hablar con APIs remotas y otra que realmente puede tocar los archivos que ya tienes, ejecutar una compilación, llamar a un binario local o procesar una carpeta de datos sin subirla a ningún sitio.
Como ese acceso es real, está controlado. La primera vez que una app quiere llegar al sistema de archivos o a la shell, osFoundry muestra un diálogo de permiso y la app no hace nada hasta que tú lo apruebas. El permiso es una decisión humana y explícita, no algo que la app se conceda a sí misma por defecto. Así el runtime nativo se mantiene coherente con la postura local-first de osFoundry: tus datos pueden quedarse en tu dispositivo, la app opera contra rutas y procesos locales en lugar de un viaje de ida y vuelta a la nube, y tú ves y consientes lo que se le permite hacer.
Dentro de osFoundry, el runtime nativo convive con el resto del espacio de trabajo, el mismo lugar donde usas el chat y los agentes, escribes código y guardas conocimiento y datos. Una app que construyas o instales puede pasar de ser una herramienta puramente conectada a la red a una que participa en tu entorno local, mientras que el modelo BYOK hace que las partes de IA de esa app funcionen con tus propias claves, sin recargo de intermediarios. El runtime es una capacidad de escritorio: depende de estar en tu máquina, que es justo lo que hace posible el acceso al sistema de archivos y a la shell, y lo que permite razonar sobre él con seguridad.
Capacidades principales
- Ejecuta una app como un proceso nativo de escritorio, no como una vista web aislada, para que actúe sobre tu máquina real
- Lee y escribe archivos locales directamente, dejando que las apps trabajen con carpetas y datos que ya están en tu dispositivo
- Invoca comandos de shell y binarios locales desde dentro de la app, para compilaciones, scripts y tareas del sistema
- Cada solicitud al sistema de archivos y a la shell pasa por un diálogo de permiso explícito que apruebas antes de que se ejecute nada
- Local-first por diseño: el trabajo se queda en tu dispositivo en lugar de viajar a la nube, y la IA funciona con tus propias claves BYOK
Casos de uso
- Desarrollador: construir una app que ejecute una suite de pruebas o un script de compilación local vía shell y muestre los resultados en el espacio de trabajo
- Analista de datos: apuntar una app a una carpeta de CSV en disco y procesarlos ahí mismo, sin subir los archivos a ningún sitio
- Usuario preocupado por la privacidad: usar una herramienta que lee documentos locales de forma nativa, aprobando el acceso al sistema de archivos una sola vez desde el diálogo de permiso
Preguntas frecuentes
¿Puede una app de osFoundry acceder de verdad a mi sistema de archivos y a mi shell?
Sí, en el escritorio una app puede ejecutarse como proceso nativo con acceso real al sistema de archivos y a la shell. No es un sandbox de navegador. Ese acceso está controlado: la app debe obtener tu aprobación mediante un diálogo de permiso antes de poder leer archivos o ejecutar comandos.
¿Cómo se mantiene seguro el runtime nativo si puede ejecutar comandos de shell?
El acceso no es automático. Cuando una app quiere el sistema de archivos o la shell, osFoundry muestra un diálogo de permiso y la app permanece bloqueada hasta que lo apruebas. Tú decides qué se le permite hacer, lo que encaja con el modelo local-first en el que tus datos pueden quedarse en tu dispositivo.
¿Está disponible el runtime nativo en la versión web?
Es una capacidad de escritorio. Ejecutarse como proceso nativo con acceso al sistema de archivos y a la shell depende de estar en tu propia máquina, que es lo que hace posible ese acceso en primer lugar. Los contextos web no conceden ese alcance local.