Should lax mode disable the project check?

csvance commented

2026-05-12 05:52:11 -07:00

(Migrated from github.com)

When running Kaimon in a containerized environment, it would be nice to be able to disable the project check so a session could be started anywhere. The current workaround is scanning everything in the container's workspace for Project.toml and configuring projects.json with all of the paths that match. This works fine, but its at least worth considering a completely unrestriced mode for more seamless integration into isolated container workflows.

kahliburke commented

2026-06-08 23:07:12 -07:00

(Migrated from github.com)

@csvance I'm not sure I 100% understand the situation you're running into. Could we discuss it a bit more. Also, sorry for the delayed response.

csvance commented

2026-06-09 08:49:34 -07:00

(Migrated from github.com)

@kahliburke if I spin up Kaimon insider of a container / VM that is created per session, currently it refuses to work in any directory that isn't added as a "project". That means I need to manually find all of the directories it could consider a project (subdirs with Project.toml) and add them to its configuration on startup each time I make a new session. This doesn't apply to persistent workflows where Kaimon is running on the users system and they configure it one time, adding each project they want.

kahliburke commented

2026-06-16 02:12:06 -07:00

(Migrated from github.com)

@csvance Thanks for explaining — that makes sense. For an ephemeral per-session container, the container is the security boundary, so repopulating the allow-list every session is just friction.

For 2.0 I added an opt-in to disable the allow-list: set "allow_any_project": true at the top level of projects.json:

{
  "allow_any_project": true,
  "projects": []
}

With it set, start_session runs in any directory that has a Project.toml (the isdir/Project.toml checks still apply). The server logs a warning at startup when it's on, so it's never silent.

I kept it separate from the security mode (strict/relaxed/lax) on purpose — those gate transport/auth (API key, IP), a different axis from filesystem scope, and folding it into lax would silently drop the guardrail for people using lax just for local convenience. A single explicit flag in the file that defines the allow-list felt clearer, and it bakes into a container image the same way an env var would.

This is on the 2.0 branch. Let me know if it fits your workflow.

@csvance Thanks for explaining — that makes sense. For an ephemeral per-session container, the container is the security boundary, so repopulating the allow-list every session is just friction. For 2.0 I added an opt-in to disable the allow-list: set `"allow_any_project": true` at the top level of `projects.json`: ```json { "allow_any_project": true, "projects": [] } ``` With it set, `start_session` runs in any directory that has a `Project.toml` (the `isdir`/`Project.toml` checks still apply). The server logs a warning at startup when it's on, so it's never silent. I kept it separate from the security mode (`strict`/`relaxed`/`lax`) on purpose — those gate transport/auth (API key, IP), a different axis from filesystem scope, and folding it into `lax` would silently drop the guardrail for people using `lax` just for local convenience. A single explicit flag in the file that defines the allow-list felt clearer, and it bakes into a container image the same way an env var would. This is on the 2.0 branch. Let me know if it fits your workflow.

👍 1

kahliburke commented

2026-06-16 02:16:49 -07:00

(Migrated from github.com)

Implemented for the 2.0.0 release (59dcb3a) — allow_any_project in projects.json. Reopen if it doesn't fit your container workflow.

Implemented for the 2.0.0 release (`59dcb3a`) — `allow_any_project` in projects.json. Reopen if it doesn't fit your container workflow.

Rows
Columns

Should lax mode disable the project check? #46