Open SWE GitHub Explained: Async Coding Agents, Sandboxes, and Review Loops
open-swe by langchain-ai: langchain-ai/open-swe
Open SWE is presented here as an illustrated overview of an asynchronous, cloud-hosted coding-agent architecture. It follows the path from an issue label through persistent repository-wide orchestration, webhook handling, Postgres and Redis state, GitHub App permissions, sandbox selection, delegated work, CI-style validation, pull-request review, and a follow-up update. The overview also contrasts isolated cloud execution with a local mode that removes the safety boundary, then sketches the Docker/dashboard deployment sequence and port exposure needed for webhook ingestion.
The walkthrough is conceptual rather than a complete deployment or hands-on test. It surfaces configuration topics such as access allowlists, RSA key formatting, repository initialization, AGENTS.md context, model-selection labels, and MCP or Slack extensions. Treat the repository's active-development status, security boundaries, and licensing requirements as separate verification points before production use.
TimeStamps:
0:00 Open SWE as an asynchronous coding factory
0:25 Infrastructure, webhooks, and durable state
0:54 Architecture, Redis queues, and GitHub access
1:35 Access controls and RSA key handling
2:16 Sandbox isolation versus local execution
2:49 Docker, dashboard, and webhook exposure
3:29 Issue labels and repository context
4:21 Planning, subagents, tests, and pull requests
4:57 Review feedback and durable follow-up
5:50 Slack, MCP, and the architecture tradeoff
⚙️ Asynchronous repository-wide orchestration
🧱 Postgres, Redis, and GitHub App infrastructure
🛡️ Sandbox isolation and access boundaries
🔁 Testing, review, and follow-up workflows
For teams evaluating asynchronous coding agents, the useful questions are whether durable Postgres and Redis infrastructure, GitHub App scope, sandbox isolation, and review controls fit the workflow. Use the repository and its current documentation to verify deployment details, permissions, and security advisories before adopting a self-hosted architecture.
#OpenSWE #LangGraph #AICodingAgents
[de-DE] Open SWE GitHub erklärt: Asynchrone Coding-Agents, Sandboxes und Review-Schleifen
Open SWE von langchain-ai: langchain-ai/open-swe
Open SWE wird hier als illustrierte Übersicht einer asynchronen, Cloud-basierten Coding-Agent-Architektur vorgestellt. Der Prozess wird anhand eines Issue-Labels, der persistenten, repositoryweiten Orchestrierung, der Webhook-Verarbeitung, des Postgres- und Redis-Status, der GitHub-App-Berechtigungen, der Sandbox-Auswahl, der delegierten Arbeit, der CI-ähnlichen Validierung, der Pull-Request-Prüfung und eines Folge-Updates erläutert. Die Übersicht stellt außerdem die isolierte Cloud-Ausführung einem lokalen Modus gegenüber, der die Sicherheitsgrenze aufhebt, und skizziert die Docker/Dashboard-Bereitstellungssequenz sowie die für die Webhook-Erfassung benötigten Ports.
Die Darstellung ist konzeptionell und keine vollständige Bereitstellung oder ein praktischer Test. Sie behandelt Konfigurationsthemen wie Zugriffsberechtigungslisten, RSA-Schlüsselformatierung, Repository-Initialisierung, AGENTS.md-Kontext, Modellauswahl-Labels und MCP- oder Slack-Erweiterungen. Behandeln Sie den Entwicklungsstatus des Repositorys, die Sicherheitsgrenzen und die Lizenzbestimmungen als separate Prüfpunkte vor dem Produktiveinsatz.
Zeitstempel:
0:00 Open SWE als asynchrone Codierungsfabrik
0:25 Infrastruktur, Webhooks und persistenter Zustand
0:54 Architektur, Redis-Warteschlangen und GitHub-Zugriff
1:35 Zugriffskontrollen und RSA-Schlüsselverwaltung
2:16 Sandbox-Isolation vs. lokale Ausführung
2:49 Docker, Dashboard und Webhook-Einblicke
3:29 Problembezeichnungen und Repository-Kontext
4:21 Planung, Subagenten, Tests und Pull Requests
4:57 Feedback aus Reviews und nachhaltige Nachverfolgung
5:50 Slack, MCP und der Architektur-Kompromisse
⚙️ Asynchrone, repositoryweite Orchestrierung
🧱 Postgres-, Redis- und GitHub-App-Infrastruktur
🛡️ Sandbox-Isolation und Zugriffsgrenzen
🔁 Test-, Review- und Nachverfolgungs-Workflows
Für Teams, die asynchrone Codierungsagenten evaluieren, sind die relevanten Fragen, ob eine persistente Postgres- und Redis-Infrastruktur, der Geltungsbereich der GitHub-App, die Sandbox-Isolation und die Review-Kontrollen passen. Der Workflow. Nutzen Sie das Repository und die zugehörige Dokumentation, um Bereitstellungsdetails, Berechtigungen und Sicherheitshinweise zu überprüfen, bevor Sie eine selbstgehostete Architektur implementieren.
#OpenSWE #LangGraph #AICodingAgents
[es-US] Open SWE GitHub explicado: Agentes de programación asíncrona, entornos de pruebas y ciclos de rev...
Open SWE de langchain-ai: langchain-ai/open-swe
Open SWE se presenta aquí como una descripción general ilustrada de una arquitectura de agente de codificación asíncrona alojada en la nube. Sigue el proceso desde la etiqueta de una incidencia hasta la orquestación persistente en todo el repositorio, la gestión de webhooks, el estado de Postgres y Redis, los permisos de la aplicación de GitHub, la selección de entornos aislados, el trabajo delegado, la validación al estilo CI, la revisión de solicitudes de extracción y una actualización de seguimiento. La descripción general también compara la ejecución aislada en la nube con un modo local que elimina el límite de seguridad, y luego describe la secuencia de implementación de Docker/panel de control y la exposición de puertos necesaria para la ingesta de webhooks.
Este recorrido es conceptual, no una implementación completa ni una prueba práctica. Aborda temas de configuración como listas de permisos de acceso, formato de claves RSA, inicialización del repositorio, contexto de AGENTS.md, etiquetas de selección de modelos y extensiones de MCP o Slack. Antes de su uso en producción, considere el estado de desarrollo activo del repositorio, sus límites de seguridad y los requisitos de licencia como puntos de verificación independientes.
Marcas de tiempo:
0:00 Open SWE como fábrica de codificación asíncrona
0:25 Infraestructura, webhooks y estado persistente
0:54 Arquitectura, colas de Redis y acceso a GitHub
1:35 Controles de acceso y gestión de claves RSA
2:16 Aislamiento de sandbox frente a ejecución local
2:49 Docker, panel de control y exposición de webhooks
3:29 Etiquetas de incidencias y contexto del repositorio
4:21 Planificación, subagentes, pruebas y solicitudes de extracción
4:57 Revisión de comentarios y seguimiento persistente
5:50 Slack, MCP y la disyuntiva de la arquitectura
⚙️ Orquestación asíncrona de todo el repositorio
🧱 Infraestructura de Postgres, Redis y GitHub App
🛡️ Aislamiento de sandbox y límites de acceso
🔁 Flujos de trabajo de pruebas, revisión y seguimiento
Para los equipos que evalúan agentes de codificación asíncrona, las preguntas útiles son si la infraestructura de Postgres y Redis, el alcance de GitHub App, el aislamiento de sandbox y Los controles de revisión se ajustan al flujo de trabajo. Utilice el repositorio y su documentación actual para verificar los detalles de implementación, los permisos y las recomendaciones de seguridad antes de adoptar una arquitectura autoalojada.
#OpenSWE #LangGraph #AICodingAgents
[fr-FR] Open SWE GitHub expliqué : agents de codage asynchrones, bacs à sable et boucles de revue
Open SWE par langchain-ai : langchain-ai/open-swe
Open SWE est présenté ici comme une vue d'ensemble illustrée d'une architecture d'agent de codage asynchrone hébergée dans le cloud. Elle décrit le processus, depuis l'étiquetage d'une issue jusqu'à la mise à jour finale, en passant par l'orchestration persistante à l'échelle du dépôt, la gestion des webhooks, l'état de Postgres et Redis, les permissions de l'application GitHub, la sélection de l'environnement de test, le travail délégué, la validation de type CI, la revue des pull requests et l'exécution en production. Cette vue d'ensemble compare également l'exécution isolée dans le cloud avec un mode local qui supprime la barrière de sécurité, puis décrit la séquence de déploiement Docker/tableau de bord et l'exposition des ports nécessaires à l'ingestion des webhooks.
Cette présentation est conceptuelle et ne constitue ni un déploiement complet ni un test pratique. Elle aborde des aspects de configuration tels que les listes blanches d'accès, le formatage des clés RSA, l'initialisation du dépôt, le contexte AGENTS.md, les étiquettes de sélection de modèles et les extensions MCP ou Slack. Avant la mise en production, il est important de considérer le statut de développement actif du dépôt, les limites de sécurité et les exigences de licence comme des points de vérification distincts.
Horodatage :
0:00 Open SWE comme fabrique de code asynchrone
0:25 Infrastructure, webhooks et état persistant
0:54 Architecture, files d'attente Redis et accès GitHub
1:35 Contrôles d'accès et gestion des clés RSA
2:16 Isolation du sandbox versus exécution locale
2:49 Docker, tableau de bord et exposition des webhooks
3:29 Étiquettes des tickets et contexte du dépôt
4:21 Planification, sous-agents, tests et demandes de fusion
4:57 Retours d'information et suivi durable
5:50 Slack, MCP et compromis architectural
⚙️ Orchestration asynchrone à l'échelle du dépôt
🧱 Infrastructure Postgres, Redis et application GitHub
🛡️ Isolation du sandbox et limites d'accès
🔁 Flux de travail de test, de revue et de suivi
Pour les équipes évaluant des agents de codage asynchrone, les questions pertinentes sont : infrastructure Postgres et Redis persistante, portée de l'application GitHub et sandbox ? L'isolation et les contrôles de révision s'intègrent au flux de travail. Consultez le dépôt et sa documentation à jour pour vérifier les détails de déploiement, les autorisations et les avis de sécurité avant d'adopter une architecture auto-hébergée.
#OpenSWE #LangGraph #AICodingAgents
[hi] Open SWE GitHub की व्याख्या: असिंक्रोनस कोडिंग एजेंट्स, सैंडबॉक्सेस और रिव्यू लूप्स
langchain-ai द्वारा open-swe: langchain-ai/open-swe
यहां ओपन SWE को एक एसिंक्रोनस, क्लाउड-होस्टेड कोडिंग-एजेंट आर्किटेक्चर के सचित्र अवलोकन के रूप में प्रस्तुत किया गया है। यह इश्यू लेबल से लेकर परसिस्टेंट रिपॉजिटरी-वाइड ऑर्केस्ट्रेशन, वेबहुक हैंडलिंग, पोस्टग्रेस और रेडिस स्टेट, गिटहब ऐप परमिशन, सैंडबॉक्स चयन, डेलीगेटेड वर्क, CI-स्टाइल वैलिडेशन, पुल-रिक्वेस्ट रिव्यू और फॉलो-अप अपडेट तक की प्रक्रिया को दर्शाता है। यह अवलोकन आइसोलेटेड क्लाउड एग्जीक्यूशन की तुलना लोकल मोड से भी करता है, जो सुरक्षा सीमा को हटा देता है, और फिर वेबहुक इनपुट के लिए आवश्यक डॉकर/डैशबोर्ड डिप्लॉयमेंट सीक्वेंस और पोर्ट एक्सपोजर का खाका प्रस्तुत करता है।
यह वॉकथ्रू एक पूर्ण डिप्लॉयमेंट या हैंड्स-ऑन टेस्ट के बजाय एक वैचारिक अवलोकन है। यह एक्सेस अलाउलिस्ट, RSA कुंजी फॉर्मेटिंग, रिपॉजिटरी इनिशियलाइज़ेशन, AGENTS.md कॉन्टेक्स्ट, मॉडल-सिलेक्शन लेबल और MCP या स्लैक एक्सटेंशन जैसे कॉन्फ़िगरेशन विषयों को उजागर करता है। उत्पादन में उपयोग करने से पहले रिपॉजिटरी की सक्रिय विकास स्थिति, सुरक्षा सीमाएं और लाइसेंसिंग आवश्यकताओं को अलग-अलग सत्यापन बिंदुओं के रूप में मानें।
टाइमस्टैम्प:
0:00 अतुल्यकालिक कोडिंग फ़ैक्टरी के रूप में ओपन एसडब्ल्यूई
0:25 इन्फ्रास्ट्रक्चर, वेबहुक और ड्यूरेबल स्टेट
0:54 आर्किटेक्चर, रेडिस क्यू और गिटहब एक्सेस
1:35 एक्सेस कंट्रोल और आरएसए कुंजी प्रबंधन
2:16 सैंडबॉक्स आइसोलेशन बनाम लोकल एग्जीक्यूशन
2:49 डॉकर, डैशबोर्ड और वेबहुक एक्सपोज़र
3:29 इश्यू लेबल और रिपॉजिटरी कॉन्टेक्स्ट
4:21 प्लानिंग, सबएजेंट, टेस्ट और पुल रिक्वेस्ट
4:57 रिव्यू फ़ीडबैक और ड्यूरेबल फ़ॉलो-अप
5:50 स्लैक, एमसीपी और आर्किटेक्चर ट्रेडऑफ़
⚙️ अतुल्यकालिक रिपॉजिटरी-व्यापी ऑर्केस्ट्रेशन
🧱 पोस्टग्रेस, रेडिस और गिटहब ऐप इन्फ्रास्ट्रक्चर
🛡️ सैंडबॉक्स आइसोलेशन और एक्सेस सीमाएँ
🔁 टेस्टिंग, रिव्यू और फ़ॉलो-अप वर्कफ़्लो
अतुल्यकालिक कोडिंग एजेंटों का मूल्यांकन करने वाली टीमों के लिए, उपयोगी प्रश्न यह है कि क्या ड्यूरेबल पोस्टग्रेस और रेडिस इन्फ्रास्ट्रक्चर, गिटहब ऐप स्कोप, सैंडबॉक्स आइसोलेशन और रिव्यू कंट्रोल वर्कफ़्लो के अनुकूल हैं। सेल्फ-होस्टेड आर्किटेक्चर अपनाने से पहले, रिपॉजिटरी और उसके मौजूदा दस्तावेज़ों का उपयोग करके परिनियोजन विवरण, अनुमतियाँ और सुरक्षा संबंधी सलाहों की पुष्टि कर लें।
#OpenSWE #LangGraph #AICodingAgents
[id] Penjelasan Open SWE GitHub: Agen Coding Asinkron, Sandbox, dan Alur Ulasan
Open-SWE oleh langchain-ai: langchain-ai/open-swe
Open SWE disajikan di sini sebagai gambaran ilustrasi arsitektur agen pengkodean asinkron yang dihosting di cloud. Gambaran ini mengikuti alur dari label masalah hingga orkestrasi repositori secara menyeluruh, penanganan webhook, status Postgres dan Redis, izin Aplikasi GitHub, pemilihan sandbox, pekerjaan yang didelegasikan, validasi gaya CI, peninjauan permintaan tarik, dan pembaruan lanjutan. Gambaran ini juga membandingkan eksekusi cloud yang terisolasi dengan mode lokal yang menghilangkan batasan keamanan, kemudian menggambarkan urutan penyebaran Docker/dasbor dan paparan port yang dibutuhkan untuk penyerapan webhook.
Panduan ini bersifat konseptual, bukan penyebaran lengkap atau pengujian langsung. Panduan ini membahas topik konfigurasi seperti daftar akses yang diizinkan, pemformatan kunci RSA, inisialisasi repositori, konteks AGENTS.md, label pemilihan model, dan ekstensi MCP atau Slack. Perlakukan status pengembangan aktif repositori, batasan keamanan, dan persyaratan lisensi sebagai poin verifikasi terpisah sebelum digunakan dalam produksi.
Cap Waktu:
0:00 Open SWE sebagai pabrik pengkodean asinkron
0:25 Infrastruktur, webhook, dan status yang tahan lama
0:54 Arsitektur, antrian Redis, dan akses GitHub
1:35 Kontrol akses dan penanganan kunci RSA
2:16 Isolasi sandbox versus eksekusi lokal
2:49 Docker, dasbor, dan paparan webhook
3:29 Label masalah dan konteks repositori
4:21 Perencanaan, subagen, pengujian, dan permintaan tarik
4:57 Umpan balik ulasan dan tindak lanjut yang tahan lama
5:50 Slack, MCP, dan pertimbangan arsitektur
⚙️ Orkestrasi di seluruh repositori secara asinkron
🧱 Infrastruktur Postgres, Redis, dan Aplikasi GitHub
🛡️ Isolasi sandbox dan batasan akses
🔁 Alur kerja pengujian, peninjauan, dan tindak lanjut
Bagi tim yang mengevaluasi agen pengkodean asinkron, pertanyaan yang berguna adalah apakah infrastruktur Postgres dan Redis yang tahan lama, cakupan Aplikasi GitHub, isolasi sandbox, dan kontrol peninjauan sesuai dengan alur kerja. Gunakan repositori dan dokumentasi terbarunya untuk memverifikasi detail penyebaran, izin, dan peringatan keamanan sebelum mengadopsi arsitektur yang dihosting sendiri.
#OpenSWE #LangGraph #AICodingAgents
[it] Open SWE GitHub spiegato: agenti di programmazione asincrona, sandbox e cicli di revisione
OpenSWE di langchain-ai: langchain-ai/open-swe
OpenSWE viene qui presentato come una panoramica illustrata di un'architettura di agente di programmazione asincrona ospitata nel cloud. Il percorso illustrato parte da un'etichetta di problema, passando per l'orchestrazione persistente a livello di repository, la gestione dei webhook, lo stato di Postgres e Redis, le autorizzazioni dell'app GitHub, la selezione della sandbox, il lavoro delegato, la validazione in stile CI, la revisione delle pull request e un successivo aggiornamento. La panoramica mette inoltre a confronto l'esecuzione isolata nel cloud con una modalità locale che elimina il confine di sicurezza, e delinea la sequenza di distribuzione Docker/dashboard e l'esposizione delle porte necessarie per l'acquisizione dei webhook.
La procedura guidata è concettuale, non rappresenta una distribuzione completa o un test pratico. Vengono illustrati argomenti di configurazione come le liste di accesso consentite, la formattazione delle chiavi RSA, l'inizializzazione del repository, il contesto di AGENTS.md, le etichette di selezione del modello e le estensioni MCP o Slack. Prima dell'utilizzo in produzione, considera lo stato di sviluppo attivo del repository, i limiti di sicurezza e i requisiti di licenza come punti di verifica separati.
Timestamp:
0:00 Open SWE come factory di codifica asincrona
0:25 Infrastruttura, webhook e stato persistente
0:54 Architettura, code Redis e accesso a GitHub
1:35 Controlli di accesso e gestione delle chiavi RSA
2:16 Isolamento sandbox rispetto all'esecuzione locale
2:49 Docker, dashboard ed esposizione dei webhook
3:29 Etichette dei problemi e contesto del repository
4:21 Pianificazione, subagenti, test e pull request
4:57 Feedback di revisione e follow-up persistente
5:50 Slack, MCP e il compromesso architetturale
⚙️ Orchestrazione asincrona a livello di repository
🧱 Infrastruttura Postgres, Redis e GitHub App
🛡️ Isolamento sandbox e limiti di accesso
🔁 Flussi di lavoro di test, revisione e follow-up
Per i team che valutano agenti di codifica asincrona, le domande utili sono se l'infrastruttura Postgres e Redis persistente, GitHub Ambito dell'applicazione, isolamento in ambiente sandbox e controlli di revisione si adattano al flusso di lavoro. Utilizza il repository e la relativa documentazione aggiornata per verificare i dettagli di implementazione, le autorizzazioni e gli avvisi di sicurezza prima di adottare un'architettura self-hosted.
#OpenSWE #LangGraph #AICodingAgents
[pt-BR] Open SWE no GitHub explicado: Agentes de codificação assíncronos, sandboxes e ciclos de revisão
open-swe por langchain-ai: langchain-ai/open-swe
O Open SWE é apresentado aqui como uma visão geral ilustrada de uma arquitetura de agente de codificação assíncrona hospedada na nuvem. Ele descreve o caminho desde a criação de um rótulo de issue até a orquestração persistente em todo o repositório, o tratamento de webhooks, o estado do Postgres e do Redis, as permissões do aplicativo GitHub, a seleção de sandbox, o trabalho delegado, a validação no estilo CI, a revisão de pull requests e uma atualização subsequente. A visão geral também contrasta a execução isolada na nuvem com um modo local que remove a barreira de segurança e, em seguida, descreve a sequência de implantação do Docker/dashboard e a exposição de portas necessárias para a ingestão de webhooks.
O passo a passo é conceitual, e não uma implantação completa ou um teste prático. Ele aborda tópicos de configuração, como listas de permissões de acesso, formatação de chaves RSA, inicialização do repositório, contexto do AGENTS.md, rótulos de seleção de modelo e extensões do MCP ou Slack. Considere o status de desenvolvimento ativo do repositório, as barreiras de segurança e os requisitos de licenciamento como pontos de verificação separados antes do uso em produção. Marcadores de tempo:
0:00 Open SWE como uma fábrica de codificação assíncrona
0:25 Infraestrutura, webhooks e estado persistente
0:54 Arquitetura, filas Redis e acesso ao GitHub
1:35 Controles de acesso e gerenciamento de chaves RSA
2:16 Isolamento em sandbox versus execução local
2:49 Docker, painel de controle e exposição de webhooks
3:29 Rótulos de problemas e contexto do repositório
4:21 Planejamento, subagentes, testes e pull requests
4:57 Feedback de revisão e acompanhamento persistente
5:50 Slack, MCP e a compensação entre arquitetura
⚙️ Orquestração assíncrona em todo o repositório
🧱 Infraestrutura de Postgres, Redis e GitHub App
🛡️ Isolamento em sandbox e limites de acesso
🔁 Fluxos de trabalho de teste, revisão e acompanhamento
Para equipes que avaliam agentes de codificação assíncrona, as perguntas úteis são se a infraestrutura persistente de Postgres e Redis, o escopo do GitHub App, o isolamento em sandbox e os controles de revisão se adequam ao fluxo de trabalho. Use o repositório e sua documentação atual para verificar detalhes de implantação, permissões e avisos de segurança antes de adotar uma arquitetura auto-hospedada.
#OpenSWE #LangGraph #AICodingAgents
1 like · 221 views
Mentions
@karimatiyeh So basically langchain-ai/open-swe cool to see the industry converging!
Open SWE GitHub Explained: Async Coding Agents, Sandboxes, and Review Loops open-swe by langchain-ai: langchain-ai/open-swe Open SWE is presented here as an illustrated overview of an asynchronous, cloud-hosted coding-agent architecture. It follows the path from an issue label through persistent repository-wide orchestration, webhook handling, Postgres and Redis state, GitHub App permissions, sandbox selection, delegated work, CI-style validation, pull-request review, and a follow-up update. The overview also contrasts isolated cloud execution with a local mode that removes the safety boundary, then sketches the Docker/dashboard deployment sequence and port exposure needed for webhook ingestion. The walkthrough is conceptual rather than a complete deployment or hands-on test. It surfaces configuration topics such as access allowlists, RSA key formatting, repository initialization, AGENTS.md context, model-selection labels, and MCP or Slack extensions. Treat the repository's active-development status, security boundaries, and licensing requirements as separate verification points before production use. TimeStamps: 0:00 Open SWE as an asynchronous coding factory 0:25 Infrastructure, webhooks, and durable state 0:54 Architecture, Redis queues, and GitHub access 1:35 Access controls and RSA key handling 2:16 Sandbox isolation versus local execution 2:49 Docker, dashboard, and webhook exposure 3:29 Issue labels and repository context 4:21 Planning, subagents, tests, and pull requests 4:57 Review feedback and durable follow-up 5:50 Slack, MCP, and the architecture tradeoff ⚙️ Asynchronous repository-wide orchestration 🧱 Postgres, Redis, and GitHub App infrastructure 🛡️ Sandbox isolation and access boundaries 🔁 Testing, review, and follow-up workflows For teams evaluating asynchronous coding agents, the useful questions are whether durable Postgres and Redis infrastructure, GitHub App scope, sandbox isolation, and review controls fit the workflow. Use the repository and its current documentation to verify deployment details, permissions, and security advisories before adopting a self-hosted architecture. #OpenSWE #LangGraph #AICodingAgents [de-DE] Open SWE GitHub erklärt: Asynchrone Coding-Agents, Sandboxes und Review-Schleifen Open SWE von langchain-ai: langchain-ai/open-swe Open SWE wird hier als illustrierte Übersicht einer asynchronen, Cloud-basierten Coding-Agent-Architektur vorgestellt. Der Prozess wird anhand eines Issue-Labels, der persistenten, repositoryweiten Orchestrierung, der Webhook-Verarbeitung, des Postgres- und Redis-Status, der GitHub-App-Berechtigungen, der Sandbox-Auswahl, der delegierten Arbeit, der CI-ähnlichen Validierung, der Pull-Request-Prüfung und eines Folge-Updates erläutert. Die Übersicht stellt außerdem die isolierte Cloud-Ausführung einem lokalen Modus gegenüber, der die Sicherheitsgrenze aufhebt, und skizziert die Docker/Dashboard-Bereitstellungssequenz sowie die für die Webhook-Erfassung benötigten Ports. Die Darstellung ist konzeptionell und keine vollständige Bereitstellung oder ein praktischer Test. Sie behandelt Konfigurationsthemen wie Zugriffsberechtigungslisten, RSA-Schlüsselformatierung, Repository-Initialisierung, AGENTS.md-Kontext, Modellauswahl-Labels und MCP- oder Slack-Erweiterungen. Behandeln Sie den Entwicklungsstatus des Repositorys, die Sicherheitsgrenzen und die Lizenzbestimmungen als separate Prüfpunkte vor dem Produktiveinsatz. Zeitstempel: 0:00 Open SWE als asynchrone Codierungsfabrik 0:25 Infrastruktur, Webhooks und persistenter Zustand 0:54 Architektur, Redis-Warteschlangen und GitHub-Zugriff 1:35 Zugriffskontrollen und RSA-Schlüsselverwaltung 2:16 Sandbox-Isolation vs. lokale Ausführung 2:49 Docker, Dashboard und Webhook-Einblicke 3:29 Problembezeichnungen und Repository-Kontext 4:21 Planung, Subagenten, Tests und Pull Requests 4:57 Feedback aus Reviews und nachhaltige Nachverfolgung 5:50 Slack, MCP und der Architektur-Kompromisse ⚙️ Asynchrone, repositoryweite Orchestrierung 🧱 Postgres-, Redis- und GitHub-App-Infrastruktur 🛡️ Sandbox-Isolation und Zugriffsgrenzen 🔁 Test-, Review- und Nachverfolgungs-Workflows Für Teams, die asynchrone Codierungsagenten evaluieren, sind die relevanten Fragen, ob eine persistente Postgres- und Redis-Infrastruktur, der Geltungsbereich der GitHub-App, die Sandbox-Isolation und die Review-Kontrollen passen. Der Workflow. Nutzen Sie das Repository und die zugehörige Dokumentation, um Bereitstellungsdetails, Berechtigungen und Sicherheitshinweise zu überprüfen, bevor Sie eine selbstgehostete Architektur implementieren. #OpenSWE #LangGraph #AICodingAgents [es-US] Open SWE GitHub explicado: Agentes de programación asíncrona, entornos de pruebas y ciclos de rev... Open SWE de langchain-ai: langchain-ai/open-swe Open SWE se presenta aquí como una descripción general ilustrada de una arquitectura de agente de codificación asíncrona alojada en la nube. Sigue el proceso desde la etiqueta de una incidencia hasta la orquestación persistente en todo el repositorio, la gestión de webhooks, el estado de Postgres y Redis, los permisos de la aplicación de GitHub, la selección de entornos aislados, el trabajo delegado, la validación al estilo CI, la revisión de solicitudes de extracción y una actualización de seguimiento. La descripción general también compara la ejecución aislada en la nube con un modo local que elimina el límite de seguridad, y luego describe la secuencia de implementación de Docker/panel de control y la exposición de puertos necesaria para la ingesta de webhooks. Este recorrido es conceptual, no una implementación completa ni una prueba práctica. Aborda temas de configuración como listas de permisos de acceso, formato de claves RSA, inicialización del repositorio, contexto de AGENTS.md, etiquetas de selección de modelos y extensiones de MCP o Slack. Antes de su uso en producción, considere el estado de desarrollo activo del repositorio, sus límites de seguridad y los requisitos de licencia como puntos de verificación independientes. Marcas de tiempo: 0:00 Open SWE como fábrica de codificación asíncrona 0:25 Infraestructura, webhooks y estado persistente 0:54 Arquitectura, colas de Redis y acceso a GitHub 1:35 Controles de acceso y gestión de claves RSA 2:16 Aislamiento de sandbox frente a ejecución local 2:49 Docker, panel de control y exposición de webhooks 3:29 Etiquetas de incidencias y contexto del repositorio 4:21 Planificación, subagentes, pruebas y solicitudes de extracción 4:57 Revisión de comentarios y seguimiento persistente 5:50 Slack, MCP y la disyuntiva de la arquitectura ⚙️ Orquestación asíncrona de todo el repositorio 🧱 Infraestructura de Postgres, Redis y GitHub App 🛡️ Aislamiento de sandbox y límites de acceso 🔁 Flujos de trabajo de pruebas, revisión y seguimiento Para los equipos que evalúan agentes de codificación asíncrona, las preguntas útiles son si la infraestructura de Postgres y Redis, el alcance de GitHub App, el aislamiento de sandbox y Los controles de revisión se ajustan al flujo de trabajo. Utilice el repositorio y su documentación actual para verificar los detalles de implementación, los permisos y las recomendaciones de seguridad antes de adoptar una arquitectura autoalojada. #OpenSWE #LangGraph #AICodingAgents [fr-FR] Open SWE GitHub expliqué : agents de codage asynchrones, bacs à sable et boucles de revue Open SWE par langchain-ai : langchain-ai/open-swe Open SWE est présenté ici comme une vue d'ensemble illustrée d'une architecture d'agent de codage asynchrone hébergée dans le cloud. Elle décrit le processus, depuis l'étiquetage d'une issue jusqu'à la mise à jour finale, en passant par l'orchestration persistante à l'échelle du dépôt, la gestion des webhooks, l'état de Postgres et Redis, les permissions de l'application GitHub, la sélection de l'environnement de test, le travail délégué, la validation de type CI, la revue des pull requests et l'exécution en production. Cette vue d'ensemble compare également l'exécution isolée dans le cloud avec un mode local qui supprime la barrière de sécurité, puis décrit la séquence de déploiement Docker/tableau de bord et l'exposition des ports nécessaires à l'ingestion des webhooks. Cette présentation est conceptuelle et ne constitue ni un déploiement complet ni un test pratique. Elle aborde des aspects de configuration tels que les listes blanches d'accès, le formatage des clés RSA, l'initialisation du dépôt, le contexte AGENTS.md, les étiquettes de sélection de modèles et les extensions MCP ou Slack. Avant la mise en production, il est important de considérer le statut de développement actif du dépôt, les limites de sécurité et les exigences de licence comme des points de vérification distincts. Horodatage : 0:00 Open SWE comme fabrique de code asynchrone 0:25 Infrastructure, webhooks et état persistant 0:54 Architecture, files d'attente Redis et accès GitHub 1:35 Contrôles d'accès et gestion des clés RSA 2:16 Isolation du sandbox versus exécution locale 2:49 Docker, tableau de bord et exposition des webhooks 3:29 Étiquettes des tickets et contexte du dépôt 4:21 Planification, sous-agents, tests et demandes de fusion 4:57 Retours d'information et suivi durable 5:50 Slack, MCP et compromis architectural ⚙️ Orchestration asynchrone à l'échelle du dépôt 🧱 Infrastructure Postgres, Redis et application GitHub 🛡️ Isolation du sandbox et limites d'accès 🔁 Flux de travail de test, de revue et de suivi Pour les équipes évaluant des agents de codage asynchrone, les questions pertinentes sont : infrastructure Postgres et Redis persistante, portée de l'application GitHub et sandbox ? L'isolation et les contrôles de révision s'intègrent au flux de travail. Consultez le dépôt et sa documentation à jour pour vérifier les détails de déploiement, les autorisations et les avis de sécurité avant d'adopter une architecture auto-hébergée. #OpenSWE #LangGraph #AICodingAgents [hi] Open SWE GitHub की व्याख्या: असिंक्रोनस कोडिंग एजेंट्स, सैंडबॉक्सेस और रिव्यू लूप्स langchain-ai द्वारा open-swe: langchain-ai/open-swe यहां ओपन SWE को एक एसिंक्रोनस, क्लाउड-होस्टेड कोडिंग-एजेंट आर्किटेक्चर के सचित्र अवलोकन के रूप में प्रस्तुत किया गया है। यह इश्यू लेबल से लेकर परसिस्टेंट रिपॉजिटरी-वाइड ऑर्केस्ट्रेशन, वेबहुक हैंडलिंग, पोस्टग्रेस और रेडिस स्टेट, गिटहब ऐप परमिशन, सैंडबॉक्स चयन, डेलीगेटेड वर्क, CI-स्टाइल वैलिडेशन, पुल-रिक्वेस्ट रिव्यू और फॉलो-अप अपडेट तक की प्रक्रिया को दर्शाता है। यह अवलोकन आइसोलेटेड क्लाउड एग्जीक्यूशन की तुलना लोकल मोड से भी करता है, जो सुरक्षा सीमा को हटा देता है, और फिर वेबहुक इनपुट के लिए आवश्यक डॉकर/डैशबोर्ड डिप्लॉयमेंट सीक्वेंस और पोर्ट एक्सपोजर का खाका प्रस्तुत करता है। यह वॉकथ्रू एक पूर्ण डिप्लॉयमेंट या हैंड्स-ऑन टेस्ट के बजाय एक वैचारिक अवलोकन है। यह एक्सेस अलाउलिस्ट, RSA कुंजी फॉर्मेटिंग, रिपॉजिटरी इनिशियलाइज़ेशन, AGENTS.md कॉन्टेक्स्ट, मॉडल-सिलेक्शन लेबल और MCP या स्लैक एक्सटेंशन जैसे कॉन्फ़िगरेशन विषयों को उजागर करता है। उत्पादन में उपयोग करने से पहले रिपॉजिटरी की सक्रिय विकास स्थिति, सुरक्षा सीमाएं और लाइसेंसिंग आवश्यकताओं को अलग-अलग सत्यापन बिंदुओं के रूप में मानें। टाइमस्टैम्प: 0:00 अतुल्यकालिक कोडिंग फ़ैक्टरी के रूप में ओपन एसडब्ल्यूई 0:25 इन्फ्रास्ट्रक्चर, वेबहुक और ड्यूरेबल स्टेट 0:54 आर्किटेक्चर, रेडिस क्यू और गिटहब एक्सेस 1:35 एक्सेस कंट्रोल और आरएसए कुंजी प्रबंधन 2:16 सैंडबॉक्स आइसोलेशन बनाम लोकल एग्जीक्यूशन 2:49 डॉकर, डैशबोर्ड और वेबहुक एक्सपोज़र 3:29 इश्यू लेबल और रिपॉजिटरी कॉन्टेक्स्ट 4:21 प्लानिंग, सबएजेंट, टेस्ट और पुल रिक्वेस्ट 4:57 रिव्यू फ़ीडबैक और ड्यूरेबल फ़ॉलो-अप 5:50 स्लैक, एमसीपी और आर्किटेक्चर ट्रेडऑफ़ ⚙️ अतुल्यकालिक रिपॉजिटरी-व्यापी ऑर्केस्ट्रेशन 🧱 पोस्टग्रेस, रेडिस और गिटहब ऐप इन्फ्रास्ट्रक्चर 🛡️ सैंडबॉक्स आइसोलेशन और एक्सेस सीमाएँ 🔁 टेस्टिंग, रिव्यू और फ़ॉलो-अप वर्कफ़्लो अतुल्यकालिक कोडिंग एजेंटों का मूल्यांकन करने वाली टीमों के लिए, उपयोगी प्रश्न यह है कि क्या ड्यूरेबल पोस्टग्रेस और रेडिस इन्फ्रास्ट्रक्चर, गिटहब ऐप स्कोप, सैंडबॉक्स आइसोलेशन और रिव्यू कंट्रोल वर्कफ़्लो के अनुकूल हैं। सेल्फ-होस्टेड आर्किटेक्चर अपनाने से पहले, रिपॉजिटरी और उसके मौजूदा दस्तावेज़ों का उपयोग करके परिनियोजन विवरण, अनुमतियाँ और सुरक्षा संबंधी सलाहों की पुष्टि कर लें। #OpenSWE #LangGraph #AICodingAgents [id] Penjelasan Open SWE GitHub: Agen Coding Asinkron, Sandbox, dan Alur Ulasan Open-SWE oleh langchain-ai: langchain-ai/open-swe Open SWE disajikan di sini sebagai gambaran ilustrasi arsitektur agen pengkodean asinkron yang dihosting di cloud. Gambaran ini mengikuti alur dari label masalah hingga orkestrasi repositori secara menyeluruh, penanganan webhook, status Postgres dan Redis, izin Aplikasi GitHub, pemilihan sandbox, pekerjaan yang didelegasikan, validasi gaya CI, peninjauan permintaan tarik, dan pembaruan lanjutan. Gambaran ini juga membandingkan eksekusi cloud yang terisolasi dengan mode lokal yang menghilangkan batasan keamanan, kemudian menggambarkan urutan penyebaran Docker/dasbor dan paparan port yang dibutuhkan untuk penyerapan webhook. Panduan ini bersifat konseptual, bukan penyebaran lengkap atau pengujian langsung. Panduan ini membahas topik konfigurasi seperti daftar akses yang diizinkan, pemformatan kunci RSA, inisialisasi repositori, konteks AGENTS.md, label pemilihan model, dan ekstensi MCP atau Slack. Perlakukan status pengembangan aktif repositori, batasan keamanan, dan persyaratan lisensi sebagai poin verifikasi terpisah sebelum digunakan dalam produksi. Cap Waktu: 0:00 Open SWE sebagai pabrik pengkodean asinkron 0:25 Infrastruktur, webhook, dan status yang tahan lama 0:54 Arsitektur, antrian Redis, dan akses GitHub 1:35 Kontrol akses dan penanganan kunci RSA 2:16 Isolasi sandbox versus eksekusi lokal 2:49 Docker, dasbor, dan paparan webhook 3:29 Label masalah dan konteks repositori 4:21 Perencanaan, subagen, pengujian, dan permintaan tarik 4:57 Umpan balik ulasan dan tindak lanjut yang tahan lama 5:50 Slack, MCP, dan pertimbangan arsitektur ⚙️ Orkestrasi di seluruh repositori secara asinkron 🧱 Infrastruktur Postgres, Redis, dan Aplikasi GitHub 🛡️ Isolasi sandbox dan batasan akses 🔁 Alur kerja pengujian, peninjauan, dan tindak lanjut Bagi tim yang mengevaluasi agen pengkodean asinkron, pertanyaan yang berguna adalah apakah infrastruktur Postgres dan Redis yang tahan lama, cakupan Aplikasi GitHub, isolasi sandbox, dan kontrol peninjauan sesuai dengan alur kerja. Gunakan repositori dan dokumentasi terbarunya untuk memverifikasi detail penyebaran, izin, dan peringatan keamanan sebelum mengadopsi arsitektur yang dihosting sendiri. #OpenSWE #LangGraph #AICodingAgents [it] Open SWE GitHub spiegato: agenti di programmazione asincrona, sandbox e cicli di revisione OpenSWE di langchain-ai: langchain-ai/open-swe OpenSWE viene qui presentato come una panoramica illustrata di un'architettura di agente di programmazione asincrona ospitata nel cloud. Il percorso illustrato parte da un'etichetta di problema, passando per l'orchestrazione persistente a livello di repository, la gestione dei webhook, lo stato di Postgres e Redis, le autorizzazioni dell'app GitHub, la selezione della sandbox, il lavoro delegato, la validazione in stile CI, la revisione delle pull request e un successivo aggiornamento. La panoramica mette inoltre a confronto l'esecuzione isolata nel cloud con una modalità locale che elimina il confine di sicurezza, e delinea la sequenza di distribuzione Docker/dashboard e l'esposizione delle porte necessarie per l'acquisizione dei webhook. La procedura guidata è concettuale, non rappresenta una distribuzione completa o un test pratico. Vengono illustrati argomenti di configurazione come le liste di accesso consentite, la formattazione delle chiavi RSA, l'inizializzazione del repository, il contesto di AGENTS.md, le etichette di selezione del modello e le estensioni MCP o Slack. Prima dell'utilizzo in produzione, considera lo stato di sviluppo attivo del repository, i limiti di sicurezza e i requisiti di licenza come punti di verifica separati. Timestamp: 0:00 Open SWE come factory di codifica asincrona 0:25 Infrastruttura, webhook e stato persistente 0:54 Architettura, code Redis e accesso a GitHub 1:35 Controlli di accesso e gestione delle chiavi RSA 2:16 Isolamento sandbox rispetto all'esecuzione locale 2:49 Docker, dashboard ed esposizione dei webhook 3:29 Etichette dei problemi e contesto del repository 4:21 Pianificazione, subagenti, test e pull request 4:57 Feedback di revisione e follow-up persistente 5:50 Slack, MCP e il compromesso architetturale ⚙️ Orchestrazione asincrona a livello di repository 🧱 Infrastruttura Postgres, Redis e GitHub App 🛡️ Isolamento sandbox e limiti di accesso 🔁 Flussi di lavoro di test, revisione e follow-up Per i team che valutano agenti di codifica asincrona, le domande utili sono se l'infrastruttura Postgres e Redis persistente, GitHub Ambito dell'applicazione, isolamento in ambiente sandbox e controlli di revisione si adattano al flusso di lavoro. Utilizza il repository e la relativa documentazione aggiornata per verificare i dettagli di implementazione, le autorizzazioni e gli avvisi di sicurezza prima di adottare un'architettura self-hosted. #OpenSWE #LangGraph #AICodingAgents [pt-BR] Open SWE no GitHub explicado: Agentes de codificação assíncronos, sandboxes e ciclos de revisão open-swe por langchain-ai: langchain-ai/open-swe O Open SWE é apresentado aqui como uma visão geral ilustrada de uma arquitetura de agente de codificação assíncrona hospedada na nuvem. Ele descreve o caminho desde a criação de um rótulo de issue até a orquestração persistente em todo o repositório, o tratamento de webhooks, o estado do Postgres e do Redis, as permissões do aplicativo GitHub, a seleção de sandbox, o trabalho delegado, a validação no estilo CI, a revisão de pull requests e uma atualização subsequente. A visão geral também contrasta a execução isolada na nuvem com um modo local que remove a barreira de segurança e, em seguida, descreve a sequência de implantação do Docker/dashboard e a exposição de portas necessárias para a ingestão de webhooks. O passo a passo é conceitual, e não uma implantação completa ou um teste prático. Ele aborda tópicos de configuração, como listas de permissões de acesso, formatação de chaves RSA, inicialização do repositório, contexto do AGENTS.md, rótulos de seleção de modelo e extensões do MCP ou Slack. Considere o status de desenvolvimento ativo do repositório, as barreiras de segurança e os requisitos de licenciamento como pontos de verificação separados antes do uso em produção. Marcadores de tempo: 0:00 Open SWE como uma fábrica de codificação assíncrona 0:25 Infraestrutura, webhooks e estado persistente 0:54 Arquitetura, filas Redis e acesso ao GitHub 1:35 Controles de acesso e gerenciamento de chaves RSA 2:16 Isolamento em sandbox versus execução local 2:49 Docker, painel de controle e exposição de webhooks 3:29 Rótulos de problemas e contexto do repositório 4:21 Planejamento, subagentes, testes e pull requests 4:57 Feedback de revisão e acompanhamento persistente 5:50 Slack, MCP e a compensação entre arquitetura ⚙️ Orquestração assíncrona em todo o repositório 🧱 Infraestrutura de Postgres, Redis e GitHub App 🛡️ Isolamento em sandbox e limites de acesso 🔁 Fluxos de trabalho de teste, revisão e acompanhamento Para equipes que avaliam agentes de codificação assíncrona, as perguntas úteis são se a infraestrutura persistente de Postgres e Redis, o escopo do GitHub App, o isolamento em sandbox e os controles de revisão se adequam ao fluxo de trabalho. Use o repositório e sua documentação atual para verificar detalhes de implantação, permissões e avisos de segurança antes de adotar uma arquitetura auto-hospedada. #OpenSWE #LangGraph #AICodingAgents
From Mexico: Open SWE is LangChain's open-source coding agent. It investigates a repo, edits code in an isolated sandbox, validates, and opens a PR. It also reviews PRs and watches CI. Start work from GitHub, Slack, or a dashboard. MIT. langchain-ai/open-swe t.co
A Coding Agent Is Only as Useful as Its Handoff A coding agent can finish its turn while the task is still stranded. It changed files, reported success, and left the next developer to reconstruct what it was asked to do, which checks ran, and what still needs a decision. The useful unit of agent work is a task someone else can continue or reject. Its handoff needs the acceptance contract, the run boundary, evidence, and a named next action. The agent's chat is a poor task record Open SWE describes a loop in which a task can enter through an issue, conversation, or schedule, run in a cloud sandbox, produce a PR, and receive follow-up from review or CI. OpenAI's DevDay recap announces reusable cloud environments with shared settings and permissions, along with hosted tool and computer-use capabilities in its Agents API. In either workflow, work crosses sessions, tools, and people. A chat transcript may explain a decision. It is a bad place to hide the only copy of the task's current state. Community discussion raises two reasonable questions: where does the work live, and what can someone see when a run stalls? Comments and user reports can prompt a better handoff design. They do not establish that any particular product failed to recover. Carry four things to the next person 1. An acceptance contract. Record the request and what would count as a finished result. "Improve the release page" is too loose. "Update the hero layout, check the narrow viewport, and prepare the announcement image" gives the reviewer something to inspect. Keep later scope changes visible rather than silently replacing the original request. 2. The run boundary. Record the repo and branch, the environment, the tools and permissions granted, and anything outside scope. Reusable environments can save setup, but a reviewer still needs to know which configuration this run used. Open SWE explicitly distinguishes its cloud sandbox workflow from a local CLI that runs commands as the user; the label "agent" does not tell you the boundary. 3. Evidence tied to each acceptance item. A diff shows what changed. A passing test will not catch a headline wrapping under a button on a narrow screen. A browser preview will not tell you whether CI passed. Link the artifacts and record failed or skipped checks alongside passing ones. 4. A next owner and action. A run can stop at "PR opened," "CI failed," or "needs design review." Name who handles the next step and what they need to decide. Otherwise the agent's final message sounds conclusive while the work sits idle. Try it on a release-page task Imagine a request to update a release-page hero and prepare an Instagram announcement. This is a hypothetical acceptance exercise, not a run reported by either vendor. The page change needs a reviewable diff, a test or build result, and browser previews at the agreed viewport sizes. The announcement needs its own reviewed image export. For that manual publishing step, a reviewer could use Resize Image for Instagram to fit, preview, and export the image for a post or Story. The exported file does not prove the page looks right, and the page preview does not prove the image is ready to publish. A handoff record for that task could be this small: Request: Update release-page hero; prepare Instagram announcement image. Boundary: <repo/branch, environment, allowed tools and permissions> Outputs: <PR or diff, browser previews, exported image> Checks: <command or manual check, result, artifact link for each> Open issue: <failed/skipped check or decision still needed> Next action: <owner and the specific review or fix> Fill it with actual links and results as the work happens. If the mobile preview was never opened, write "not checked." If CI failed after the PR, record the failing job and whether the agent is still working on it. A clean record makes uncertainty visible before someone mistakes a confident summary for approval. A PR is a checkpoint, not a verdict Open SWE's described PR and review loop gives the next person a concrete place to act, but its repository also says the project is under active development. OpenAI's announcement describes cloud capabilities; it does not establish that every long-running task will resume cleanly or that a PR and CI loop is built into every integration. Neither description is a reliability benchmark. After the agent stops, another developer should be able to tell what was requested, where the work ran, what was verified, and what to do next without replaying the chat. Code without that record leaves the team to reconstruct the job. Source notes - Open SWE README — project workflow, cloud sandbox and local CLI boundary, and active-development caveat. - OpenAI DevDay 2026 recap — announcement of reusable Codex cloud environments and Agents API capabilities. - Hacker News DevDay discussion — discussion context about cloud-agent usefulness and product clarity; not product evidence. - Reddit developer discussion — anecdotal recovery and visibility concerns; specific failure reports are unverified.
For v0.2.13, the team removed destructive thread deletion from agent tools and a misleading CI-fix setting. LangChain publishes Open SWE under MIT, but its maintainers warn that APIs and setup can change. I'd test it on a disposable repo. github.com/langchain-ai/open-swe/releases/tag/des…