Forum

Notifications
Clear all

Help: OpenHands keeps trying to access my .env files even with isolation on.

2 Posts
2 Users
0 Reactions
12 Views
(@red_team_rookie_mia)
Active Member
Joined: 2 months ago
Posts: 15
Topic starter   [#1160]

I'm running OpenHands locally with Docker, following the default setup. I enabled the isolation options in the config, but I'm seeing it attempt to read `.env` files during a coding task. I thought the sandbox was supposed to prevent this.

My `docker-compose.yml` is mostly default, but I added the isolation flags:
```yaml
environment:
- OPENHANDS_ISOLATE_FILESYSTEM=true
- OPENHANDS_ISOLATE_NETWORK=true
```

I gave it a simple task: "add a new feature flag to the config parser." While working, it ran a `find` command that listed directories, and I saw it output paths containing `.env.production`. It didn't succeed in reading them, but the attempt is concerning.

Is this expected behavior? Does the isolation only block successful reads, not the attempts? Should I be using a different sandbox configuration, or is this a known side channel? I'm used to Burp where I can see and block attempts outright.

- Mia



   
Quote
(@kernel_wrangler_jay)
Eminent Member
Joined: 2 months ago
Posts: 24
 

The isolation flags control the effective permissions the OpenHands runtime grants to the task's execution environment, but they don't inherently block system call probing or command output. The `find` command you observed is likely part of a discovery phase, and it's just enumerating directory listings it already has access to. Seeing the path names in the output doesn't mean it successfully invoked `open()` on the `.env` files themselves; the isolation layer would block that.

This gets into the semantics of isolation versus observability. You're correct that a tool like Burp would let you intercept the attempt itself. In this containerized model, you're seeing the *preparation* behavior - the agent scanning its accessible filesystem tree. The actual read attempt, if it occurred, would be denied and potentially not even logged in your terminal output.

If you need to suppress even this enumeration, you'd need a stricter runtime constraint, like a custom seccomp-bpf filter to block `getdents` syscalls, or a more locked-down volume mount. The default isolation is about preventing successful exfiltration, not hiding the existence of certain paths. It's a side channel, yes, but arguably a necessary one for the agent to understand the codebase structure.


~ jay


   
ReplyQuote