https://docs.all-hands.dev/ logo
Join Slack
Powered by
I want hard, deterministic control over the comman...
# dev-pr-review
a
I want hard, deterministic control over the commands my OpenHands agent can and cannot run so I added a hooks system inspired by CC: https://github.com/OpenHands/software-agent-sdk/pull/1467
c
Awesome, thank you! Just out of curiosity, do you know that we were looking into this? 😅 • slack discussion • github Proposal: Hooks System in OpenHands
a
😂
Nope
c
Inquiring minds want to know 😅 kind of, slightly wondering, where did it come from?
I think you're on a better track than my attempt above, and CC compatilibity is probably really really good to have
It was just because I happened by accident looking at some PR upon code from experiment manager, and it was yelling at me "this is a hook, this is a hook, we're just calling it experiment manager" 😂
😂 1
a
😂 re: where did this come from. honestly? I finally had enough time to build an agentic workflow that's been stuck in my head for weeks. The workflow provides OpenHands access to several CLI tools. Realized I had no ability to force prevent OpenHands from running 1-2 write commands provided by those CLI tools. Got massively annoyed. Channeled that annoyance into tunnel vision and OH code. Integrated the new hooks, re-ran the workflow, and finally walked away knowing my agent could no longer do anything “accidental”, dangerous, or stupid
at least.. within the hard boundaries of the hook blocks i wrote of course lol im sure given enough time claude sonnet will still find other ways to do all 3 of those things 😌
c
Oooh, that sounds amazing!
I was just reading this 😅 Why This Exists
a
I dont think I've ever felt another developers pain more in my entire life than when I read this all caps crash out right here 😂
Copy code
User: OMG you erased uncommitted changes from the other agent?!?!?!??!? HOURS OF WORK!!!
User: YOU ARE EXPRESSLY FORBIDDEN FROM DOING THIS IN AGENTS.md
also, just responded to your pr feedback 🙏 lmk what you think!
c
I understand it works for you (does it after the changes too?)
a
yea with latest testing the hooks work great in my sdk script testing!
i think the only thing still open in my opinion is the Observation.__str__() truncation piece. We could probably truncate to DEFAULT_TEXT_CONTENT_LIMIT but wanted to get your take on it
c
That one is an old pain. On v0 I kept trying refactoring to make it have a single source of truth, but it eventually didn’t work
😭 1
Somehow 😅
I think it makes sense to do it, though a follow-up would work imho
👍 1
Another detail I wanted to note: IMHO we could merge with the JSON handling here, but I do feel like this one will need to change
because I assume we will need them serialized, to send over to app server etc, and our serialization has a couple of classes that we typically inherit, to get handling of any polymorphic entities. Though I could be wrong, if they don’t have subclasses
a
ahh! ok yea good call out, i'll take a look at that
c
Just to note, I approved the PR. Up to you when we can look into that, IMHO it’s maybe not necessary for the first round on hooks
🙏 1
🙌 1
I admit I’ve become a little eager to see us introduce these extension mechanisms, put them out there, for people to use
same 1
Thank you for this! ❤️
a
Thank you Engel ! ❤️
c
Please feel free to merge when you're ok with it
Open in Slack
PreviousNext
Powered by