[FEATURE] Global memory / shared instructions for Xcode Claude Agent
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
The Xcode Claude Agent's auto-memory system is per-project, with no built-in way to share knowledge across projects. Developers working on multiple Xcode projects need a way to define global preferences and patterns that apply everywhere — similar to how ~/.claude/CLAUDE.md works for the Claude Code CLI (or an include statement in source code).
Problem
Each Xcode project gets its own MEMORY.md file under ClaudeAgentConfig/projects/<mangled-path>/memory/. This works well for project-specific knowledge, but there's no mechanism for cross-project settings like:
• How to address the user
• File header credit preferences
• Shared architectural patterns across projects (e.g., iOS 26/Liquid Glass conventions)
• Common tool usage notes (e.g., "use Python scripts for large .xcstrings files")
• Platform-specific knowledge (e.g., iPadOS minimum window sizes)
Without global memory, the agent starts fresh on every new project with no awareness of the developer's established preferences or conventions.
What I tried
- ~/.claude/settings.json SessionStart hook — Does not fire for the Xcode Agent. Only works for the Claude Code CLI.
- ~/.claude/CLAUDE.md — Also CLI-only. The Xcode Agent doesn't read it.
- #include-style directive in MEMORY.md — Placed a reference to an external file in each project's MEMORY.md. The agent treated it as informational text and didn't act on it.
Proposed Solution
Suggested solutions (any would help)
• Global memory file: Support a GLOBAL_MEMORY.md (or similar) in ClaudeAgentConfig/ that the Xcode Agent reads automatically at the start of every conversation
• Make hooks work for Xcode Agent: Have ~/.claude/settings.json SessionStart hooks fire for the Xcode Agent, not just the CLI
• Protected MEMORY.md sections: Allow a section of MEMORY.md that auto-memory won't overwrite, so user-injected directives persist
• Support ~/.claude/CLAUDE.md in Xcode Agent: Read the same global instructions file that the CLI uses
Environment
• macOS 15.5 / Xcode 26 beta
• Claude Agent in Xcode (not Claude Code CLI)
• Multiple Objective-C projects sharing common UIKit patterns
Alternative Solutions
I tried the ~/claude/settings.json hooks suggested by others here, but they simply don't fire for the Xcode Agent, whether SessionStart or UserPromptSubmit.
What actually works (workaround)
Claude helped me create a two-part system:
- A GLOBAL_MEMORY.md file in the ClaudeAgentConfig/ directory as a single source of truth for cross-project knowledge.
- A macOS LaunchAgent that runs a shell script every 30 seconds. The script monitors all project directories under ClaudeAgentConfig/projects/ and:
• Creates a MEMORY.md with a strongly-worded directive for any project directory that doesn't have one
• Prepends the directive to any existing MEMORY.md that's missing it (since the agent's auto-memory can overwrite user-seeded content)
The directive uses forceful language ("MANDATORY", "ACTION REQUIRED", "you MUST use the Read tool to read this file BEFORE responding") because softer language was ignored by the agent.
Known limitation: The very first conversation on a brand-new project won't have global memory. After that first conversation creates the project directory, the LaunchAgent injects the directive within 30 seconds, and all subsequent conversations work.
My workaround solutions might be a bit fragile. The suggested solutions would likely be more robust and benefit the entire Xcode Claude agentic coding community.
Priority
High - Significant impact on productivity
Feature Category
Configuration and settings
Use Case Example
When open a project in Xcode and first start to work with Claude, it is a blank slate. I have to teach Claude about common issues which would apply to all the projects I work on, and I dislike having to retrain Claude for every project.
Additional Context
Attached is a Claude generated explanation of our workaround along with the hook script and an aggressive "use global memory" instruction.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗