Small PR to fix local runtime, which I think may be broken: https://github.com/OpenHands/OpenHands/pull/13431 I know this code will be deprecated in 2 weeks, but I figure it’s better to not have broken code in the meantime?

Hello! I have created a couple draft PRs to make a consolidated settings object in the SDK, and use it to render the frontend settings page. • SDK PR: https://github.com/OpenHands/software-agent-sdk/pull/2361 • GUI PR: https://github.com/OpenHands/OpenHands/pull/13306 It has a few important features: 1. Settings are pydantic objects, serializable, deserializable, and migratable from old versions to new versions 2. The agent can be created entirely from the settings object 3. The fields to be displayed in the GUI can be derived from the SDK settings object so SDK upgrade = GUI upgrade 4. It is possible to override the default display behavior (see the LLM display in the frontend) Here’s a video of how it renders now (details will be fixed later of course). I’d love to have architectural comments from people like @chilly-france-44439 @calm-artist-7206 @quick-window-91705 @straight-sundown-84319 @millions-afternoon-47582 @wooden-umbrella-84098. It’s a big PR so just high-level directional feedback is good for now, and if this direction is good I’ll do: 1. More intensive testing to see what this breaks 2. Making sure it works on SaaS and doesn’t break backward compatibility

https://github.com/OpenHands/OpenHands/pull/13091 https://github.com/OpenHands/OpenHands/pull/13043 Hello team, can you please help me finish those PRs asap? I didn't get any feedback for 2 weeks

Hi everyone! Requesting a PR review for #13193 (fixes issue #13126) when someone has a chance. It adds a flag to return a 429 error when hitting sandbox limits instead of silently pausing them (default behavior is unchanged), and fixes an eviction bug that was pausing the newest sandboxes instead of the oldest. All checks passing. Thanks! PR: https://github.com/OpenHands/OpenHands/pull/13193 Issue: https://github.com/OpenHands/OpenHands/issues/13126

WDYT about this? Simple bare supply-chain protection by giving some time to newly uploaded packages to maybe discover issues. https://news.ycombinator.com/item?id=47582632 llamantino also proposed it in the npm discussion SDK PR: https://github.com/OpenHands/software-agent-sdk/pull/2648

Just a heads-up and to pick your brain a bit: • Re: Slack conversation last agent message • Re: the PR on it • Re: other clients (e.g. GH) https://github.com/OpenHands/OpenHands/issues/13714

Hi @calm-artist-7206 As a new on the OpenHands, I need your help in many ways. Could you please review my first PR and leave the feedback kindly? https://github.com/OpenHands/OpenHands/pull/13722

Frontend architecture 🧵

Per a separate discussion, remove CODEOWNERS as a first step to more meaningful review requests: https://github.com/OpenHands/OpenHands/pull/13833 cc @wooden-umbrella-84098 @quiet-night-61895 @flaky-jordan-67349

OK, my settings PR is ready for review. • @chilly-france-44439, @calm-artist-7206, and @straight-sundown-84319 you may be good reviewers for this part on the software-agent-sdk making ConversationSettings, which make it possible to create a StartConversationRequest with the appropriate settings: https://github.com/OpenHands/software-agent-sdk/pull/2789 • @straight-sundown-84319, @millions-afternoon-47582, or maybe others, you may be good reviewers for this PR incorporating the new SDK into OpenHands/OpenHands: https://github.com/OpenHands/OpenHands/pull/13306 Again, apologies that this is a very large PR, but it is all aimed at two objectives in OpenHands/OpenHands: 1. The settings menus can be dynamically created from AgentSettings, so updates to the SDK agent settings will immediately be exposed to users. 2. These settings will be plumbed all the way through to a conversation start request, so new conversations will use these settings I have checked all of the code and iterated on it a bunch, so I think the code quality is good by my standards. I have already QAed the PR once before on a somewhat older version of the code, but I’ll start doing it again now with the current version. I hope everything still works, but I might put in some small fixes if I notice anything new now. cc @ancient-car-4311 and @purple-thailand-64770 Thanks a bunch in advance everyone!

Small devops improvement, allow use of python 3.13 when running the makefile: https://github.com/OpenHands/OpenHands/pull/14012 3.13 is installed by default on openhands runtimes, so this will help prevent issues when running

make lint

for instance.

Hey all! We have a lot of new features in flight: 1. ACP agent (@strong-ice-84145) 2. LLM profiles (@modern-fireman-99755) 3. Skill update interface (@hundreds-twilight-32833), and @wide-doctor-37830 is working on skill+plugin loading. Also, I’m currently working with @millions-afternoon-47582 and @better-park-34863 to finish the first release with the new settings. One thing I’m thinking, maybe it’d be worth having a quick meeting sometime, maybe Thursday or Friday eng office hours or alternatively some time in the morning. We could cover the new settings interface, how settings automatically show up in the frontend, and how we should adjust the design to handle all of these new functionalities (cc @breezy-kilobyte-39430 as well)

To improvements to typescript-client (cc @wooden-umbrella-84098): • bring it up to date with the most recent agent-server: https://github.com/OpenHands/typescript-client/pull/125 • add pr auto-review workflow: https://github.com/OpenHands/typescript-client/pull/127

Created a prototype OpenHands UI that connects directly to the agent server, creating new conversations is super-fast 😍 https://github.com/neubig/agent-server-gui cc @wooden-umbrella-84098

I believe they use

macos-seatbelt

(for macOS, not sure about windows)

Hi all, sharing something I built that might be relevant here. A seccomp user-notify guard for AI agent command execution. Intercepts execve and execveat at the syscall boundary, runs a userspace policy check, allows expected dev tools, blocks disguised or off-policy executables, and emits a JSON audit trail. Repo: https://github.com/blazingRadar/agent-exec-guard-lab Positioned as additive to the existing Hardened Docker Installation pattern, not a replacement for Docker/gVisor isolation. Linux-only, exec-only, with a documented TOCTOU caveat on SECCOMP_USER_NOTIF_FLAG_CONTINUE. Curious whether this kind of layer is interesting to anyone working on the runtime architecture. Happy to discuss tradeoffs or share the broader lab work if useful. Cheers, Nick

Very tiny PR to prevent zombie processes: Add tini init to Dockerfile to reap zombie processes by neubig · Pull Request #3043 · OpenHands/software-agent-sdk

Fix to event callbacks to require non-null conversation and event IDs: https://github.com/OpenHands/OpenHands/pull/14557 The context is that this is our most costly DB operation (because it’s moderately expensive and very frequent) and by simplifying it we could possibly save a lot of DB CPU.

Simplification of OpenHands Provider The original issue has the most context, but the main thing is simple: • work with

openhands/

everywhere in the codebases • 'translate' the URL in the right app_proxy model/base_url only when sent to litellm • original issue SDK PR • rewrite URL only at litellm boundary • stop persisting app proxy URLs (we were saving "litellm_proxy/app...") • persist simply

openhands/

instead. fix(sdk): keep OpenHands provider#3548 This allows us to avoid quite a bit of redundant code in client apps, and the bugs that came with it Downstream cleanup PRs • OpenHands-CLI: settings: keep OpenHands provider models public OpenHands-CLI#770 ◦ Stops stamping the OpenHands proxy

base_url

when saving Basic-mode

openhands/*

settings. ◦ Keeps metadata/critic behavior recognizing

openhands/

by prefix. • agent-canvas: settings: trust public OpenHands provider models agent-canvas#1280 ◦ Removes frontend reverse-mapping helpers for

litellm_proxy/*

+ OpenHands proxy URL. ◦ Basic-mode saves no longer re-stamp the proxy base URL; the model selector reads the public model directly. • OpenHands: settings: stop reverse-mapping OpenHands provider models OpenHands#14725 ◦ Removes app-server/settings reverse conversion from

litellm_proxy/*

to

openhands/*

. ◦ Narrows OpenHands-provider checks and managed-proxy overrides to the public

openhands/

prefix.

Re: releases without testing? For context, on agent-sdk repo, and partially spread to other repos, we run the release skill with: • open release PR • run all tests from labels applied by the agent (

test-examples

,

integration-test

,

behavior-test

) • the human author is assumed to read the results in the PR comments, fix as needed • usually ask for a human review (unless you’re sure) • automatically tracks eval versions • creates release notes, for users • and version bump PRs on downstream repos @chilly-france-44439 has worked a lot to make this run smoothly for the human maintainer. I do think it’s a good policy to keep. In my understanding, @able-napkin-92802‘s attempt to fix the release process on Cloud was inspired by it. ——— However, now we tagged the latest before release PRs, so it didn’t follow this policy. I think I understand why it happened in this particular case. I do think we should not skip testing though. These tests are not run on regular PRs normally, they are more in-depth for release PRs specifically. For clarity, the policy in the linked skill applies to all releases, including patch releases, they go out in users’ hands so we can be a bit careful.. I can see an argument that patches are “easy” and clear, and one could assume tested, but… skipping tests means we don’t know that… 😓 WDYT? cc: @straight-sundown-84319 @able-napkin-92802

I ran Matt Pocock's improve codebase architecture skill on openhands. It found 5 architectural improvement opportunities 🔦 Here are the github issues: github.com/OpenHands/OpenHands/issues/15061 / github.com/OpenHands/OpenHands/issues/15062 / github.com/OpenHands/OpenHands/issues/15063 / github.com/OpenHands/OpenHands/issues/15064 / github.com/OpenHands/OpenHands/issues/15065. Already applied some agent debate between GPT and opus models like @calm-artist-7206 had done for the agent canvas architectural improvement github issues

I found this site, written by a human (with LLM expression, but human-driven) for similar reasons as @dry-book-58714 above: cc @straight-sundown-84319 @quick-window-91705 https://shapeofthesystem.com

One more, for fun. This time, an X thread, from a talk that Geoffrey Litt just gave: I’m reading in his take the amazing power we have at our fingertips now, to ask the agent to do anything, wildly different things than we did before, which we may need to fix human understanding of the system/PR/diff/control flow. That gives us ways to review beyond good ole boring “code review”: e.g. “Literate code diffs”. Or, the fun one: dynamic, interactive visualizations, like a mini-movie of how exactly does this Prolog interpreter work https://x.com/geoffreylitt/status/2072522251300409556?s=61

WDYT, how does this look like, for human understanding of a PR? Two skills, applied to the same PR. The PR they explain: split cloud API and runtime proxy calls (maybe too easy one 🫠) 1) show-me: • Cloud calls now say whether they hit the app backend or a sandbox runtime 2) teach-me • Learn the cloud proxy split well enough to audit the next one

I’d love to get a review on this from someone (maybe @straight-sundown-84319 or @strong-ice-84145)? Right now MCPs don’t seem to work on the OH cloud if they need authentication, and I think this fixes it: github.com/OpenHands/OpenHands/pull/15103

Re: using release-please with pre-release testing github.com/OpenHands/release-actions/pull/18 cc: @able-napkin-92802 Just my thoughts here. Approx since ~November 2025, since the agent-sdk repo took shape, and Rohit built the cli repo on it, we had a flow like: • ~8/10 things that we tried in the agent-sdk • when we saw they worked, or sometimes immediately • applied them downstream too, in oh/oh, in cli. in extensions, docs, repos. These are diverse things, e.g. how the agent can help with triage -> workflow; what we need to yell at the LLM; how to ensure that the agent doesn’t break compatibility downstream (CI). Basically, we were trying and learning what the agent can and cannot do, and apply guardrails or nudges or info as needed. (Rohit also did a bunch of stuff making the CLI codebase agent-friendly, including periodic workflows to help fix its code design.) The way I see it, the same goes for release PRs automated testing: currently in the sdk, we are testing real-world examples, to catch subtle regressions, that might not be seen in unit tests. Also, we just added a security scan: sanity checks that between the previous release and the current release PR, there is no suspicious dependency added (it checks security database), and the like. I plan to do something similar: add such automated checks on release PRs in downstream repos, too, as appropriate. ——— TL;DR: I understand you see it as different if you look in isolation; I suggest though, that it’s not that the agent-sdk release actions would be “much different than the ones applied to other repos”; rather, on this one, we are still to apply them to other repos.

For the record, people are trying 3d as help for the human brain, to navigate or understand architecture/flow in codebases These on-the-fly -ish visualizations are a prompt or a skill away, now.

Should we keep compatibility with Node 22, or could we take everything to 24+ ?

This is an example seen on the internet of how PR descriptions could, actually, look like: in human English, and, with pseudocode ☕

Upgrades to Node 24: • agent-sdk PR • openhands PR There's also an extensions PR in progress (from 20 to 24) I'd love to know if there are concerns with going through with it