Extending and Contributing to OpenHands
1. Start with the narrowest owning area​
OpenHands is broad enough that you should choose one layer first:
| Goal | First place to look |
|---|---|
| Agent runtime behavior | openhands/ |
| UI improvements | frontend/ |
| Execution environment work | containers/ and config |
| Validation | tests/ |
| Docs or contributor onboarding | official docs and repo guidance |
2. Why layer boundaries matter​
Because the product mixes agent behavior, UI, and sandboxed execution, large cross-cutting patches can become hard to review fast. Small, layer-aware changes are much easier to land safely.
3. Best first contributions​
The highest-leverage first contributions are usually:
- setup and docs fixes,
- targeted runtime bug fixes,
- frontend clarity improvements,
- test coverage for common regressions,
- sandbox or config ergonomics.
4. Think end to end​
In OpenHands, a contribution is only really correct if the full developer loop still works:
- task assignment,
- repo inspection,
- command execution,
- file edit,
- review of output.
5. Before opening a PR​
Read the contribution guidance, validate the workflow you changed, and keep your first patch narrow enough that maintainers can understand it without replaying an entire agent session.