Together with Modal, I’m happy to announce that the Sovereign Tech Agency is investing nearly €510k into Flatpak development. The focus is on closing gaps in Flatpak’s sandboxing story: new portals for audio, networking, VPNs, and spell checking, plus infrastructure work on entitlements and intents.
I’ll be leading the technical side alongside Adrian, with organizational support from Kateryna and Cade. We’ve brought on a great team and the project will ramp up over the coming months through the end of 2027.
Read the full announcement on the Modal blog.
In Some Changes to GNOME Security Tracking, I reported:
I will discontinue tracking newly-reported security issues on November 1, 2026. During November, I will focus only on tracking issues reported prior to November 1. By December 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.
This is because I was planning to leave my job at Red Hat on December 31 due to some internal Red Hat policy changes. But this timeline has now unexpectedly moved forward two months, to October 30. Accordingly, I will now discontinue tracking newly-reported security issues on October 1, 2026. During October, I will focus only on tracking issues reported prior to October 1. By November 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.
If your agentic workload involves the agent being able to run arbitrary code (like bash or equivalent), then you should not use a “LLM as part of your app” framework like LangChain, BeeAI, OGX etc. Instead, run OpenCode, goose, or another general coding agent inside a sandbox such as OpenShell.
Sandboxing limits what the agent can access directly. For privileged effects, it is best augmented with a pattern like safe outputs: the agent emits a structured, unprivileged request that separately trusted code validates and applies.
A compact decision tree Can it run bash or arbitrary code? ├─ Yes → Run a generic agent in a sandbox └─ No → Are you *really* sure *all* of your tool calls (MCP or builtin) don't accidentally expose "execute arbitrary code"? ├─ Yes → OK, maybe LangChain or equivalent makes sense └─ No → Goto startI also think the builtin sandboxing in most agent tools (like Claude Code and Gemini CLI) is a bad idea, and it’s better to just ensure the entire thing is sandboxed.
Related to all of this, a key thing anyone making an “agent” needs to ask is “how is this different from just writing an agent skill”. From my previous post you’ll know that I think GitHub Agentic Workflows is a good reference baseline for applying agentic AI (background/task oriented) safely and effectively. And there an “agent” is almost exactly just an agent skill, but with a bit of YAML defining its integration with the outer system.
Why should it be harder than that? I just don’t see it making sense for custom agents written in frameworks like LangChain to proliferate in most use cases. Sure you can use LLMs to generate it, but it’s even more secure and understandable to not have that code at all.
Even for the use case of an interactive chat bot, do you really need a custom app versus just MCP tools for an already generic frontend? I doubt it.
I don’t think it makes sense for most organizations to have proliferation of custom bespoke agents like these LangChain-style frameworks encourage. Skills and sandboxed generic agents are just easier to understand and work with.
Hello! I'm Angelo Verlain, a Software Engineering student, and I've been working for the last 3 months easing the debugging process of GJS apps by adding Debug Adapter Protocol (DAP) support to GJS as part of Google Summer of Code (GSoC 2026).
A debugger is software for executing a computer program in an environment that allows for programming-level inspection and control. A debugger is often used to debug, but can be used for other goals including testing. Common features of a debugger include stepping through code line-by-line, breaking into the program's flow of control, managing breakpoints, and reporting and modifying memory. <sup>1</sup>
What is GJS?GJS or GNOME JavaScript is a JavaScript interpreter that allows developers to write code that can leverage GLib/GObject and various other libraries that work with GObject Introspection like GTK, Libsoup, etc...
In practice, GJS allows you to write GNOME/GTK Applications and GNOME Components in JavaScript. The GNOME Shell & Extensions, GNOME Weather, GNOME Audio Player, GNOME Maps, Workbench are all examples of projects powered by GJS.
What is DAP?The Debug Adapter Protocol is a a specification that describes how messages are passed between a debugger client (for example, your IDE) and server (such as the Node.js or any other language runtime). It specifies and communicates pausing & continuing execution, setting breakpoints, stepping through the code, viewing stack traces, and more. It works by defining a standard way for your development tool (e.g. GNOME Builder, VS Code, Zed, etc...) to connect to a debugger.
Today, you can already debug applications and libraries written for/with Android, Node.js, Deno, C, C++, Rust, Python and more. This project aims to make GJS applications debuggable in your favourite editor or debugger by implementing a DAP adapter for GJS.
Adding DAP to GJSGJS already supports debugging programs by use of the --debugger flag, which spins up a GDB-style CLI interface where you invoke it by running gjs --debugger [file-name].js and writing commands like breakpoint [line], step, frame to set breakpoints, step through the code and print the stack frame respectively.
It works well, but it's different from the GUI debugging that’s more popular these days.
Here's an example of GJS debugging the following code saved as test2.js
function print(i) { console.log(i); } for (let i = 0; i < 10; i++) { print(i); }If GJS had support for DAP, you wouldn’t be limited to just using the text mode debugger, but could debug applications using your favourite editor (Zed, VS Code, etc…)
The workflow would be easier too: Press F5 to debug (standard hotkey), specify the path to your entrypoint, and then run the program. To set a breakpoint, simply type the debugger keyword or click in the gutter/margin of your editor (even after your program has started execution!).
When the program reaches that breakpoint, you will have a nice stack trace showing where the program stopped, and give you options to inspect the current variables in the different scopes, continue execution, or step next, in our out of frames.
Here's an example of debugging the same script using VS Code's Node.js adapter (the experience we want):
Note that you can more clearly see the variables, call stack and breakpoints in the debugger.
ScopeMy work is focused on launching & debugging GJS apps.
The scope is also limited to launching & debugging GJS applications or running scripts in the GJS interpreter and debugging them. Attaching to already running applications is not in scope.
Concretely this also means that debugging components like the GNOME Shell is not in scope.
Furthermore, I have only written an extension for Zed since it’s the editor I use, but other editor extensions like VS Code, Builder, and Emacs could be implemented as a follow-up task and will be relatively easy since GJS itself implements the DAP specification and we just need to bridge the two. If you want support for a specific editor or debugger, please let me know :).
ProgressI've made significant progress on the project.
The project period is coming to a close and I’ve made significant progress. Currently, the following is implement:
My next steps will focus on the following:
Figure: Debugging a program with a visual debugger (Zed), showing breakpoints (red circle in the gutter), current line highlighted and variables
I’m looking forward to sharing my progress when we get to the end of the program! Expect another blog post in the next couple of weeks.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.
Read more of this story at Slashdot.