Hey 🙂 Can someone take a look at the PRs above? ^

Bug fix for agent server: https://github.com/OpenHands/software-agent-sdk/pull/3844 The startup config was being cached in authentication meaning that the session api key was not getting reset correctly when initializing in dormant mode 🙏

Are there any objections to me cutting a 1.29.1 release based on current bug fixes? (I need it for security enhancements to runtime-api)

Small PR to add /goal endpoints to the agent-server: https://github.com/OpenHands/typescript-client/pull/228

Hey, adding workflow in typescript-client to have merge-driven release: https://github.com/OpenHands/typescript-client/pull/230 (similar to the one in the sdk) If it is good. i would like to release a new version of the typescript-client today for: • testing the workflow • I need a new version for a feature

Bumping github.com/OpenHands/agent-canvas/issues/1182 @hundreds-twilight-32833 is there an issue shortlist or roadmap publicly available?

Fix for issue from the demo this morning: github.com/OpenHands/software-agent-sdk/pull/3898 🙏 (Conversations were skipped due to the rapid restart and the lease not expiring)

Are you planning on a release soon? I have a fix which I need in the SAAS env: github.com/OpenHands/software-agent-sdk/commit/b4bfa7a823cd… I would kick one off, but I see that there is new functionality in there as well as bug fixes so I guess it would be 1.30.0 rather than 1.29.4 - I just wanted to confirm. (@modern-fireman-99755 / @wide-doctor-37830)

@modern-fireman-99755 - any thoughts on the error in releasing github.com/OpenHands/software-agent-sdk/pull/3931 ? Without direction I'd be inclined to revert github.com/OpenHands/software-agent-sdk/pull/3889

github.com/OpenHands/software-agent-sdk/pull/3975 Fix for broken laminar instrumentation 🙏 (As soon as this is out I'd like to kick off release 1.30.1)

Just to note quickly: this is a bit strange to me… Why does the client know “workspace/project”? 🤔 That means that anyone trying to use or create a client on the Cloud API has to know: it does things inside “/workspace/project”, which is internal cloud implementation detail. Have we taken some time to think about REST API design? I think maybe we could make it so that the path to file is all you need, client-side. Like this example, I feel there are others, FWIW.

Hey everyone, I’ve noticed a bit of confusion in this channel. It’s meant for agent-server, but people are frequently posting SDK-related questions here (or even asking for a release of the sdk). Moreover, agent-server is actually a subset of the software-agent-sdk, and the main channel for that project is

#proj-agent

. Additionally, since this channel doesn't have many members, it’s a shame people are posting here when they could reach a much wider audience in

#proj-agent

. Could we consider one of the following options? 1. Delete this channel entirely. 2. Rename this channel to

#proj-client

(or

#proj-ts-client

), since we currently don't have a dedicated channel for that project. I'm personally leaning toward the second option, but I'm open to discussion!

Hi all, I’m wondering if we should seriously consider a sqllite database for indexing conversation metadata? I’m starting to accumulate lots of conversations on my disk, and it seems that things get a bit slow. I know others have observed this before, like @calm-artist-7206, and we have some PRs in this direction

Lazily hydrate persisted conversations: github.com/OpenHands/software-agent-sdk/pull/4100

PR to persist parent/child conversation relationships in agent-server github.com/OpenHands/software-agent-sdk/pull/4188

I've lost track of the original discussion, but we have a weird issue where conversations get lost if agent-server restarts too quickly github.com/OpenHands/software-agent-sdk/issues/4192

Fix an issue with opening ports to the outside world when a session key is not provided: github.com/OpenHands/software-agent-sdk/pull/4180

Two PRs: • perf(agent-server): index conversation execution status for search/count • perf(agent-server): evict idle conversations from memory after a configurable TTL Which will close the tracker issue: perf: SDK and agent-server performance and correctness issues from profiling investigation

Hi team I need a review/approval on this PR to prevent agent-server from OOM'ing on certain end user setups with OHE github.com/OpenHands/software-agent-sdk/pull/4323

hey friends, first time contributing. could i get some pointers on what the pull request and review process look like? i've created a pull request here but unsure what's next or if i've missed anything github.com/OpenHands/software-agent-sdk/pull/4362

Updating models for ACP github.com/OpenHands/typescript-client/pull/328 @strong-ice-84145 Could you gave a look please 🙂

Move composition of conversation info off the main agent thread to prevent deadlocks: github.com/OpenHands/software-agent-sdk/pull/4417

my agent identified this as a major cause of my agent-server starting to crawl. Fixing it locally did indeed seem to drastically improve things This is on a ~2-3 month old installation, so I might be at the frontier of where this problem kicks in github.com/OpenHands/OpenHands/pull/16438 github.com/OpenHands/OpenHands/pull/16438/changes Full disclosure, I don't fully understand the implications of cleaning up the bash history. Maybe someone here knows more?

https://github.com/OpenHands/software-agent-sdk/pull/4459 - rename telemetry event in agent server

github.com/OpenHands/software-agent-sdk/pull/4522 - add deployment kind to telemetry

github.com/OpenHands/software-agent-sdk/pull/4529 - identify automation run convo from regular convo in telemetry

small favor if anyone here has a moment: I just need

ready-for-dev

on github.com/OpenHands/software-agent-sdk/issues/4577 to unblock my PR.

Small tweak we meant to do at some point, I think maybe it should be back on the table because some e2e tests still take time and may fail for unclear reasons: run e2e suites after merge to main

Have there been any discussions about an intended boundary between

ConversationState

and

StoredConversation

? I've been running into some friction while working on the new endpoints for conversation tags, but there are at least two latent bugs lurking right now:

confirmation_policy

,

security_analyzer

, and

secrets

are all tracked by both stores and read from

stored

on startup (e.g. lines 1090–1102 of

event_service.py

), but API mutations only write to

ConversationState

. That means those changes are silently lost on conversation eviction or server restart.

tags

(what my PR addresses) is actually the only field where the API correctly keeps both stores in sync. Is this a known gap? And more broadly, is there a design doc or shared understanding of which store is authoritative for which fields? The current behavior looks like it accreted field by field rather than following a deliberate boundary.