Claude Code + Vertex AI on Fedora/Podman: context_management rejection and SELinux on user bind mounts

[ogajduse]

Hi,

I'm trying to run Claude Code inside an OpenShell sandbox on Fedora (Podman driver, SELinux enforcing, v0.0.71) with a Vertex AI provider and I've hit two issues. Wondering if I'm missing something in my setup or if these are known gaps.

Setup:

openshell provider create --name vertex --type google-vertex-ai --from-gcloud-adc \
  --config VERTEX_AI_PROJECT_ID=my-project --config VERTEX_AI_REGION=global
openshell inference set --provider vertex --model claude-opus-4-6 --no-verify
openshell sandbox create --provider vertex \
  --env ANTHROPIC_BASE_URL=https://inference.local \
  --env ANTHROPIC_API_KEY=unused \
  --driver-config-json '{"podman":{"mounts":[{"type":"bind","source":"/home/me/repos","target":"/sandbox/repos","read_only":true}]}}' \
  -- claude --bare

1) context_management: Extra inputs are not permitted

Claude Code sends a context_management field in the request body (part of the context-management-2025-06-27 beta). The router strips the anthropic-beta header for Vertex rawPredict routes (makes sense — Vertex rejects it), but the corresponding body field isn't stripped. Vertex then rejects the unknown field with 400.

I'm working around it with CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1, which works but disables all experimental features. Would it make sense for the router to strip beta-only body fields (like context_management) alongside stripping the anthropic-beta header?

2) User bind mounts don't get SELinux relabeling

On Fedora with SELinux enforcing, the bind-mounted /sandbox/repos is inaccessible to the sandbox user — SELinux blocks it because the source files have user_home_t context. I noticed that internal TLS bind mounts get the z (shared relabel) option when SELinux is detected, but user-configured bind mounts via --driver-config-json don't. Is there a way to pass mount options I'm missing, or would adding automatic z relabeling for user bind mounts on SELinux systems be a reasonable enhancement?

Thanks for any pointers.

[Advait251206]

Thanks for the detailed write-up—it makes the issues much easier to understand.

For (1), I think your analysis makes sense. If the router intentionally removes the anthropic-beta header for Vertex's rawPredict endpoint because Vertex doesn't support Anthropic beta features, then it would also be logical to remove any request body fields that are only valid when those beta features are enabled (such as context_management).

Otherwise, the request ends up in an inconsistent state:

• The header advertising the beta feature is removed.
• The beta-specific request body remains.
• Vertex validates the payload and rejects the unknown field.

Using CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 is a reasonable workaround, but it does disable all experimental functionality rather than just adapting the request for the selected provider. Automatically stripping beta-only fields when targeting providers that don't support them seems like a cleaner solution.

For (2), I don't think you're missing anything obvious either. On SELinux-enabled Podman systems, bind mounts typically need to be relabeled (:z or :Z) for the container to access files under a user's home directory. Since OpenShell already appears to account for this with its own internal mounts, extending the same behavior (or providing a way to opt into it) for user-configured bind mounts would seem like a reasonable enhancement.

It would be helpful if the maintainers could clarify:

1. Is the router expected to sanitize beta-only request fields for providers that don't support the corresponding Anthropic beta features, or is disabling experimental betas currently the intended workaround?
2. Is there an existing way to specify Podman mount options (such as :z/:Z) through --driver-config-json, or is SELinux relabeling for user bind mounts not supported yet?

Both issues sound like provider/container compatibility concerns rather than problems with your configuration, so I'd be interested to hear whether they're already on the roadmap or considered enhancement requests.

---

If this answer helped or pointed you in the right direction, I'd appreciate it if you could mark it as the accepted answer so it's easier for others with the same issue to find.

Also, if you found my contribution useful, I'd appreciate it if you could check out my GitHub profile, follow me, and star any repositories you find interesting.

GitHub: https://github.com/Advait251206