osFoundry / Platform
Runtime natif
Sur le bureau, votre application peut s'exécuter comme un processus natif avec accès au système de fichiers et au shell — encadré par une boîte de dialogue de permission.
Présentation
Le runtime natif permet à une app dans osFoundry de s'exécuter comme un véritable processus natif sur votre machine, au lieu d'être confinée à une vue web en bac à sable. Sur le bureau, cela signifie que l'app peut lire et écrire des fichiers sur votre système de fichiers local et invoquer directement des commandes shell, exactement l'accès dont dispose un programme de bureau ordinaire. C'est toute la différence entre une app qui ne peut que dialoguer avec des API distantes et une app qui peut réellement toucher aux fichiers que vous possédez déjà, lancer un build, appeler un binaire local ou traiter un dossier de données sans le téléverser où que ce soit.
Comme cet accès est réel, il est encadré. La première fois qu'une app veut atteindre le système de fichiers ou le shell, osFoundry affiche une boîte de dialogue de permission et l'app ne fait rien tant que vous n'avez pas approuvé. La permission est une décision humaine et explicite, pas un réglage par défaut que l'app s'accorde à elle-même. Le runtime natif reste ainsi fidèle à la posture local-first d'osFoundry : vos données peuvent rester sur votre appareil, l'app travaille sur des chemins et des processus locaux plutôt qu'un aller-retour vers le cloud, et vous voyez et consentez à ce qu'elle est autorisée à faire.
Au sein d'osFoundry, le runtime natif côtoie le reste de l'espace de travail, là même où vous utilisez le chat et les agents, écrivez du code, et conservez connaissances et données. Une app que vous construisez ou installez peut passer d'un outil purement connecté au réseau à un outil qui participe à votre environnement local, tandis que le modèle BYOK fait tourner les parties IA de cette app sur vos propres clés, sans marge de revendeur. Le runtime est une capacité de bureau : il dépend d'être sur votre machine, et c'est précisément ce qui rend l'accès au système de fichiers et au shell possible et sûr à raisonner.
Fonctionnalités clés
- Exécutez une app comme un processus natif de bureau, pas une vue web en bac à sable, pour qu'elle agisse sur votre vraie machine
- Lisez et écrivez des fichiers locaux directement, laissant les apps travailler sur des dossiers et des données déjà présents sur votre appareil
- Invoquez des commandes shell et des binaires locaux depuis l'app, pour les builds, les scripts et les tâches système
- Chaque requête vers le système de fichiers et le shell passe par une boîte de dialogue de permission explicite que vous approuvez avant toute exécution
- Local-first par conception : le travail reste sur votre appareil au lieu d'un aller-retour vers le cloud, et l'IA tourne sur vos propres clés BYOK
Cas d’usage
- Développeur : construire une app qui exécute une suite de tests ou un script de build local via le shell et affiche les résultats dans l'espace de travail
- Analyste de données : pointer une app vers un dossier de CSV sur le disque et les traiter sur place, sans téléverser les fichiers où que ce soit
- Utilisateur soucieux de sa vie privée : utiliser un outil qui lit des documents locaux nativement, en approuvant l'accès au système de fichiers une seule fois via la boîte de dialogue de permission
Questions fréquentes
Une app osFoundry peut-elle vraiment accéder à mon système de fichiers et à mon shell ?
Oui, sur le bureau une app peut s'exécuter comme un processus natif avec un accès réel au système de fichiers et au shell. Ce n'est pas un bac à sable de navigateur. Cet accès est encadré : l'app doit obtenir votre approbation via une boîte de dialogue de permission avant de pouvoir lire des fichiers ou exécuter des commandes.
Comment le runtime natif reste-t-il sûr s'il peut exécuter des commandes shell ?
L'accès n'est pas automatique. Lorsqu'une app veut le système de fichiers ou le shell, osFoundry affiche une boîte de dialogue de permission et l'app reste bloquée jusqu'à votre approbation. C'est vous qui décidez ce qu'elle a le droit de faire, ce qui s'accorde au modèle local-first où vos données peuvent rester sur votre appareil.
Le runtime natif est-il disponible dans la version web ?
C'est une capacité de bureau. S'exécuter comme un processus natif avec accès au système de fichiers et au shell dépend d'être sur votre propre machine, ce qui est justement ce qui rend cet accès possible. Les contextes web n'accordent pas ce type de portée locale.