[Bug]: Running Claude Code in a container crashes apps on the host system with "too many open files"

[Artur-]

I have done the following

• I have searched the existing issues
• If possible, I've reproduced the issue using the 'main' branch of this project

Steps to reproduce

https://github.com/emarc/claude-contained implements a containerized version of Claude Code (and other AI tools). It works by sharing the current folder with Claude Code running in a container.

Run that on any folder with many files (tried with https://github.com/vaadin/flow) and ask Claude to do just about anything related to files (e.g. "What files are there").

Current behavior

It will start consuming file descriptors as it iterates through files. Quite quickly you will have tens or hundreds of thousands of file descriptors in use when the project contains e.g. a node_modules folder. Then you will quite quickly reach the Mac OS file system limit and applications inside or outside the container will start crashing.

Expected behavior

It closes file descriptors after they have been used

Environment

- OS: macOS Tahoe 26.2 (25C56)
- Xcode: 
- Container: container CLI version 0.8.0 (build: release, commit: a18df81)

Relevant log output

N/A

Code of Conduct

• I agree to follow this project's Code of Conduct

[Artur-]

It does not seem to be related to Claude Code as you can notice the same effect by launching the container as claude-contained -s which only starts a shell and running find will also consume all file descriptors and cause apps to crash

[Artur-]

Here is a super simple test case: https://github.com/Artur-/test-apple-container

It creates a folder structure, a container that only runs find and a test script for running 3 containers in parallel.

In a few seconds, they fail and potential apps start crashing on the host system also

[Artur-]

Tried to reproduce by using docker instead of container but then the scripts complete successfully (after quite some time)

[crimson-knight]

This is a very clear issue, thank you for figuring this out. I was planning on using a container for Claude Code and I'm sure I would have run into this myself and lost my mind trying to figure out the root cause!

Knowing what little I know about Swift, I'm sure there is a way to memory optimize the file descriptors so that this issue is resolved. Probably a fun meta issue that Claude Code could try resolving itself.

[emarc]

I tried the test case provided (https://github.com/Artur-/test-apple-container), and can confirm it reproduces the problem (and is quick and easy to try).

Tested on container CLI version 0.8.0 (on Tahoe 26.2)

Hopefully this problem can be addressed, as it's a bit of a showstopper for anyone trying to work on real-life codebases.

[dcantah]

This partly seems like Virtualization.framework's virtiofs device behavior (an fd is held open after doing vfs lookups; this is intentional), and could be partly rlimit related in the guest as well. Will share some updates after digging in the next few days

[leonewt0n]

does adding this to ~/.zshrc and restarting your terminal fix it?

ulimit -n 64000

[dcantah]

The rlimit PR does not fix this, so reopening. It's just somewhat adjacent