Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

bug(claude): PreToolUse write gate resolves projects through another OS user's engram serve on 7437 and denies every write (regression of #1120 class)

Open
  • Is something wrong?
#2,103 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go
Domain
security

Research direction

Start with the Go hook subcommand engram hook claude-pre-tool-use and trace how it connects to the server on 127.0.0.1:7437. Reproduce the issue using the provided command while another OS account runs engram serve. Done means the hook does not adopt a server owned by another account: it uses an instance owned by the caller or returns an explicit ownership error.

Written by the indexing model from the issue text.

Description

status:needs-review type:bug
📝 Bug Description

On a machine with two OS accounts, the Claude Code PreToolUse write gate (engram hook claude-pre-tool-use) sends its project resolution to whichever engram serve answers on 127.0.0.1:7437, even when that server belongs to the other OS account. That server then tries to read the calling user's <repo>/.engram/config.json with its own UID, gets EACCES (the caller's home is mode 0700), and the hook denies every Engram write:

Claude host project resolution failed: project_resolution_failed: invalid .engram/config.json: read <repo>/.engram/config.json: open <repo>/.engram/config.json: permission denied

This looks like the same class as #1120 (closed by #1127, "isolate managed instances by data directory"), reached through a path that fix did not cover: #1127 changed the shell session-start.sh probes, while the failing caller here is the Go hook subcommand claude-pre-tool-use.

Environment
  • engram 3.5.4 (stable, contains #1127's merge commit 8ae5839)
  • Claude Code plugin engram@engram 0.1.17, Claude Code 2.1.310
  • Linux x86_64, two local OS accounts; account B runs engram serve on 127.0.0.1:7437; account A (the caller) has no engram serve of its own, only engram mcp --tools=agent
  • Account A's home is drwx------; .engram/config.json is -rw-r--r-- owned by account A
Steps to reproduce
  1. Account B starts engram serve (default port 7437).
  2. Account A opens Claude Code in a repository that has .engram/config.json, inside a 0700 home.
  3. Account A calls mem_save (any write tool matched by the PreToolUse hook).

Manual reproduction from account A's shell, outside Claude Code:

printf '%s' '{"session_id":"probe","hook_event_name":"PreToolUse","cwd":"'"$PWD"'","tool_name":"mcp__engram__mem_save","tool_input":{"title":"probe"}}' \
  | engram hook claude-pre-tool-use
Expected

The hook either uses a server owned by the calling account (or starts/finds its own instance, as #1127 does for SessionStart), or fails with an explicit ownership error that names the mismatch.

Actual

permissionDecision: "deny" with the permission denied reason above, on every write (mem_save, mem_session_summary, ...). Reads through MCP stdio keep working (mem_current_project resolves the project from config), so only writes fail.

Evidence
  • strace -e trace=openat on the hook: the hook process never opens config.json itself.
  • strace -e trace=connect on the hook: one connection to 127.0.0.1:7437.
  • The only engram serve on the machine runs as account B.
  • The calling account can read the file (cat succeeds); only the other account cannot.
  • Repeated twice within the session with the same result; no state was changed to work around it.
Security note

Because the hook adopts a server owned by another OS account, hook traffic from account A (project resolution, and potentially session and write-gate data) is handled by account B's process. Here it failed closed only because A's home is 0700; with a readable home the cross-account routing would be silent, which is the class of issue #1120 described. Loopback is a process boundary, not a user boundary (#200), so the adapter needs to verify server ownership before adopting it.

Dominant language
Go
Stars
7.1k
Forks
729
Avg merge
9h 34m
Merged PRs (30d)
335

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Gentleman-Programming/engram

All issues in Gentleman-Programming/engram

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.