osFoundry / Platform
Runtime nativo
No desktop, seu app pode rodar como um processo nativo com acesso ao sistema de arquivos e shell — controlado por um diálogo de permissão.
O que é
O runtime nativo permite que um app dentro do osFoundry seja executado como um processo nativo real na sua máquina, em vez de ficar confinado a uma visualização web isolada. No desktop, isso significa que o app pode ler e gravar arquivos no seu sistema de arquivos local e invocar comandos de shell diretamente, o mesmo acesso que um programa de desktop comum tem. Essa é a diferença entre um app que só consegue conversar com APIs remotas e um que realmente pode tocar nos arquivos que você já tem, executar um build, chamar um binário local ou processar uma pasta de dados sem enviá-la para lugar nenhum.
Como esse acesso é real, ele é controlado. Na primeira vez que um app tenta alcançar o sistema de arquivos ou o shell, o osFoundry exibe um diálogo de permissão e o app não faz nada até você aprovar. A permissão é uma decisão humana e explícita, não um padrão que o app concede a si mesmo. Isso mantém o runtime nativo coerente com a postura local-first do osFoundry: seus dados podem permanecer no seu dispositivo, o app opera contra caminhos e processos locais em vez de uma ida e volta à nuvem, e você vê e consente o que ele tem permissão para fazer.
Dentro do osFoundry, o runtime nativo fica ao lado do restante do espaço de trabalho, o mesmo lugar onde você usa chat e agentes, escreve código e guarda conhecimento e dados. Um app que você cria ou instala pode deixar de ser uma ferramenta puramente conectada à rede e passar a participar do seu ambiente local, enquanto o modelo BYOK faz com que as partes de IA desse app rodem nas suas próprias chaves, sem sobretaxa de revenda. O runtime é um recurso de desktop: depende de estar na sua máquina, que é exatamente o que torna possível o acesso ao sistema de arquivos e ao shell, e o que permite raciocinar sobre ele com segurança.
Principais recursos
- Execute um app como um processo nativo de desktop, não como uma visualização web isolada, para que ele atue na sua máquina real
- Leia e grave arquivos locais diretamente, deixando os apps trabalharem com pastas e dados que já estão no seu dispositivo
- Invoque comandos de shell e binários locais de dentro do app, para builds, scripts e tarefas de sistema
- Cada solicitação ao sistema de arquivos e ao shell passa por um diálogo de permissão explícito que você aprova antes de qualquer coisa rodar
- Local-first por design: o trabalho fica no seu dispositivo em vez de ir e voltar da nuvem, e a IA roda nas suas próprias chaves BYOK
Casos de uso
- Desenvolvedor: criar um app que executa uma suíte de testes ou um script de build local via shell e mostra os resultados no espaço de trabalho
- Analista de dados: apontar um app para uma pasta de CSVs no disco e processá-los ali mesmo, sem enviar os arquivos para lugar nenhum
- Usuário preocupado com privacidade: usar uma ferramenta que lê documentos locais de forma nativa, aprovando o acesso ao sistema de arquivos uma única vez pelo diálogo de permissão
Perguntas frequentes
Um app do osFoundry consegue mesmo acessar meu sistema de arquivos e meu shell?
Sim, no desktop um app pode rodar como processo nativo com acesso real ao sistema de arquivos e ao shell. Não é um sandbox de navegador. Esse acesso é controlado: o app precisa da sua aprovação por meio de um diálogo de permissão antes de poder ler arquivos ou executar comandos.
Como o runtime nativo se mantém seguro se ele pode executar comandos de shell?
O acesso não é automático. Quando um app quer o sistema de arquivos ou o shell, o osFoundry exibe um diálogo de permissão e o app permanece bloqueado até você aprovar. Você decide o que ele tem permissão para fazer, o que combina com o modelo local-first em que seus dados podem permanecer no seu dispositivo.
O runtime nativo está disponível na versão web?
É um recurso de desktop. Rodar como processo nativo com acesso ao sistema de arquivos e ao shell depende de estar na sua própria máquina, que é o que torna esse acesso possível em primeiro lugar. Contextos web não concedem esse tipo de alcance local.