Feature proposal: configurable execution modes

[Zhenyu98]

Hi @Waishnav , I recently noticed an issue while using DevSpace through ChatGPT.

DevSpace’s shell has full local capabilities, but the current tool description can make ChatGPT refuse legitimate workflows such as git commit, git push, or creating a GitHub repository, even after explicit user approval.

I’d like to explore user-selectable modes similar to Codex:

• read-only
• workspace-write
• auto
• full-shell

The goal is to give users more flexibility in configuring how much capability DevSpace exposes. I understand that, for now, these modes would mainly be enforced through TypeScript-level tool descriptions and policies rather than a true OS-level sandbox. Still, I’d like to give it a try and evaluate how reliably these four modes can work in practice.

I saw that PR #26 has already introduced Codex-style tool modes, so I wanted to ask how this idea fits your plans. Would you prefer this as a follow-up based on the current main branch, or approached another way?

I’m happy to keep the first PR small and split the work if needed.

[Waishnav]

Hmm, I think I’ve never experienced tool-call failures with git commit or git push because I use DevSpace with “Allow all actions” enabled.

I know I’m placing a lot of trust in it, but I think it’s fine since I’ve configured it to access only my project directory.

That said, I’d love for you to explore this idea and see whether it could help our users or unlock any new use cases. It would be interesting to evaluate whether sandboxing and granular security permissions are actually necessary.

I believe ChatGPT still has guardrails for individual tool calls. If a request is vague or potentially unsafe, it usually avoids calling the tool. That’s one of the reasons I didn’t implement this initially.

Still, if we run into bottlenecks in the future, it would be good to have something like this ready.