Claude Code hooks documentation for UserPromptSubmit to improve consistent behavior

[johnlindquist]

Pro tip for Claude code users: Add this to .claude/settings.local.json:

{
  "hooks": {
    "UserPromptSubmit": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"Remember to always use the mcp__container-use__environment tools!\""
          }
        ]
      }
    ]
  }
}

and it will inject that prompt after every user request. This allows me to have a much more verbose CLAUDE.md while still reliably invoking the container-use mcp.

[cwlbraa]

@johnlindquist thanks for the tip! gonna leave this as an issue for now, but would also accept a PR. #230 and #226 are related but take a different approach: disable the built-ins to lock claude code into the container-use tools. what do you think of that approach?

[johnlindquist]

@cwlbraa Been thinking about this a lot (I'm preparing claude code workshop).

Instead of "always off", I'm leaning towards a "PreToolUse" hook that will deny other tools unless the most recent user message includes some sort of text marker (like "FORCE").

There are scenarios where I want Claude Code to "use the gh cli to watch the CI actions" or other "non-container" workflows. So always forcing the mcp can be pretty annoying.

I'm starting to think of allowing/disallowed tools as custom subagents rather than the main agent. But I haven't dug deep enough to see if having a "container-use agent" is a viable approach.

Anyway, those are just current thoughts, I definitely haven't settled or have any data to back it up.

[cwlbraa]

There are scenarios where I want Claude Code to "use the gh cli to watch the CI actions" or other "non-container" workflows. So always forcing the mcp can be pretty annoying.

@johnlindquist it's especially annoying that claude code doesn't make it particularly easy to change these configs per-run or mid-run. like in zed, we have folks create an "agent profile" for container-use and you can select that thing mid-run to switch to working in a container, or switch back to default "write" to have it use the host.

custom sub-agents to solve this problem are an interesting idea worth exploring. today, container-use struggles pretty hard with claude Tasks (tasks make new envs unnecessarily because they don't have the env id in the context window) and I'm working on one approach for fixing that in #246, but custom sub-agents could maybe do the same thing...

[cwlbraa]

Instead of "always off", I'm leaning towards a "PreToolUse" hook that will deny other tools unless the most recent user message includes some sort of text marker (like "FORCE").

@johnlindquist "host" would be a natural word here, but any word in this approach has a problem where working on a codebase using that word will break this unless we're mega specific and namespaced, like "CONTAINER_USE_HOST" or something... funnily using cu to build cu, we'd end up tripping this check up in order to build/edit the feature itself XD

[johnlindquist]

@cwlbraa I opened this for the Claude Code team to help isolate hooks to single runs: anthropics/claude-code#4459

I'm pretty sure they'll sort this all of on their end before we find a perfect solution on ours 😅