[Feature]: Secure access to .git (hooks) directory

[magro]

Motivation

The access to the projects git directory (especially .git/hooks) is a potential security threat: written from within the sandbox, the next execution from the host executes it as well.

Proposed behavior

Prevent modification of .git/hooks

Alternatives considered

No response

[magro]

I guess superradcompany/microsandbox#1448 would help here as well...

[magro]

Here's an analysis done by Sol and Opus (maybe this is helpful):

Status

Design and threat analysis. None of this is implemented today. It reflects opencode-sandbox and
microsandbox PR #1448 as of 2026-08-31. That pull request
is open and is not contained in the microsandbox SDK version pinned by this project.

Summary

opencode-sandbox bind-mounts the host working directory as writable /workspace
(internal/sandbox/vm/vm_lifecycle.go:353-374), with the VM user sharing the host UID. Anything in the VM can
therefore rewrite host Git metadata, most obviously hooks. That code executes later on the host, as the host user, when
someone runs Git there. This delayed execution crosses the VM trust boundary.

PR #1448 adds gitignore-style deny patterns to bind mounts, enforced per filesystem operation. A name-only .git
pattern is the strongest simple policy: it covers every repository in the tree at any depth, including repositories
created after startup. Its cost is that denied entries are hidden rather than frozen, so Git can no longer work against
host repositories from inside the VM. The complete design is therefore .git denial plus Git metadata kept VM-local.

Protecting hooks alone is insufficient

Repository configuration is as dangerous as the hooks themselves. A writable config can redirect hooks with
core.hooksPath, pull in further configuration via include and includeIf, and specify commands through filters,
merge drivers, diff commands, core.fsmonitor, credential helpers, and aliases.

Any policy must therefore cover repository configuration, not just the default hooks directory.

Static protection does not fit the topology

The mount is the current working directory, not a repository. It may be a parent of many repositories:

/workspace/
  project-a/.git/
  project-b/vendor/nested-repository/.git/
  project-c/submodule/.git            # gitdir pointer file
  shared.git/                         # bare repository

Four properties defeat startup scanning and fixed read-only overlays:

• Independent repositories can sit at any depth, so finding one enclosing repository protects nothing else.
• Submodules and linked worktrees use a .git file; the real metadata lives elsewhere, possibly outside the mount.
• Bare repositories have no .git entry at all and can still run receive-side hooks.
• Repositories can be created after the VM starts, which makes any startup inventory stale.

Protection must consequently be evaluated per filesystem operation rather than computed once at startup.

Two protection models

Anthropic's sandbox-runtime protects a curated set of
mandatory deny paths, including .git/hooks/ and .git/config. Microsandbox PR #1448 takes a different approach, and
the difference decides what is achievable here:

	sandbox-runtime	microsandbox PR #1448
Effect	Writes denied, reads still allowed	Entry hidden (ENOENT) and writes rejected
Paths created later	Not covered by Linux binds	Covered; names are checked per operation
Depth	Linux scan depth defaults to 3	Unlimited for name-only patterns

Microsandbox is the better fit for the nested case because it is dynamic and depth-independent. It is not a drop-in
equivalent, though: there is no "visible but read-only" mode, which is exactly what would be needed to keep Git working
while freezing its metadata.

Applying PR #1448

The pattern to use is the name-only .git. Having no slash, it matches a file or directory of that name at any depth,
which covers nested repositories, submodule and worktree pointer files, and entries created after startup. It also
resists ancestor renames, because the protected basename is unchanged. Path-anchored patterns such as some/repo/.git
lack that property, .git/ misses pointer files, and **/.git/** leaves the .git entry itself accessible.

The trade-off is functional, not partial: hiding .git stops Git in the VM from using host repositories, so status and
diff, commits, git init under /workspace, and --worktree no longer work there. Host-side behavior is unaffected,
since project slug resolution runs on the host before VM creation.

Narrower patterns that keep metadata visible do not close the path. They miss submodule metadata under .git/modules,
miss bare repositories, and leave core.hooksPath as a redirect. They remain useful as defense in depth.

Two boundaries are worth stating plainly. The deny list matches names, not inodes, so pre-existing host symlinks or
hard links can still alias protected content. And the pattern set is fixed when the VM is created, so policy changes
require recreating it.

PR #1448 is unmerged, and its author tested only on Linux. Since this project also targets macOS, adoption requires an
upstream release plus testing on both platforms. Issue #12
already tracks the same feature for hiding secret files; hiding .env is functionally cheap, hiding .git is not.

Options

Option	Covers nested and new repos	Keeps host Git usable in VM	Assessment
Opencode permission rules	No	Yes	Advisory; bypassed by shell commands
Unix permissions or chmod	No	Partly	Same UID owns the files; not a boundary
Startup scan plus read-only overlays	Partly	Mostly	Complex and stale once the tree changes
All discovered Git dirs read-only	No	No	Strong for known repos; blocks Git mutation
PR #1448 with .git deny	Yes	No	Simple and dynamic; the recommended primitive
VM-local Git metadata	Yes	Yes, VM-local	Best separation; largest behavioral change
Post-session integrity checks	Detection only	Yes	Evidence only; a hook may already have run

Recommended direction

Combine the two bottom-half rows once PR #1448 ships. Deny .git on /workspace as a mandatory pattern that project
configuration cannot remove, include it in the mount fingerprint so changes recreate the VM, and move the repository
opencode works on into VM-local storage, exporting only reviewed working-tree changes. Bare repositories stay outside
the policy and should be detected and reported before mounting.

The present --worktree mode does not achieve this on its own, because /workspace stays writable and the worktree
still shares the host repository's common Git directory (internal/sandbox/vm/worktree.go:132-186).

If direct Git operation on host repositories must be preserved, PR #1448 is not sufficient. That would require a policy
that separates reads from writes and understands Git metadata semantically.

Interim mitigations

These reduce blast radius and are explicitly not a boundary:

• Start from a single repository rather than a parent of many, to keep unrelated projects out of the mount.
• Keep bare repositories and shared Git directories outside the mounted tree.
• After a session, inspect hooks, core.hooksPath, and config includes before running Git on the host.

Residual risk

Git metadata is one delayed-execution surface, not the only one. Build scripts, package lifecycle scripts, IDE tasks,
and .opencode-sandbox/Dockerfile, which the host builds via Docker (internal/sandbox/image/build.go:165-198), carry
the same class of risk. Hiding host Git metadata closes an important automatic path; it does not make agent-written
content safe to execute on the host.