vh/esh-pfi-infrastructure
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity

memory: Blender access stays on the shared fleet login; batch path blender-run (Prime)

Browse Source
This commit is contained in:
vh
2026-09-28 08:50:09 -07:00
parent 46276611a7
commit 6f0c480693
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
persistent-memory.md
+1 -1
View File
@@ -195,7 +195,7 @@ _As of 2026-09-27 ~0900 PT._
server runs INSIDE the container, and agents reach it as ssh+docker-exec stdio via
`scripts/blender-mcp`. No port is published, and screenshots work because server and Blender
share a filesystem. Telemetry is off and safe mode is on. Verified end to end (render, screenshot,
safe-mode refusal). **Registration: PER TASK (Prime, 2026-09-27)**: a session that needs Blender runs `claude mcp add blender -- …/scripts/blender-mcp`. It goes in NO user- or project-wide config.
safe-mode refusal). **Batch path: `scripts/blender-run`** (one-shot `docker run --rm`, `--job` staging; first user is draupnir). **Access: the shared fleet `infra-ops` login, with no render-only key (Prime, 2026-09-28).** **Registration: PER TASK (Prime, 2026-09-27)**: a session that needs Blender runs `claude mcp add blender -- …/scripts/blender-mcp`. It goes in NO user- or project-wide config.
→ `stacks/blender/README.md`
### Zigbee2MQTT on esh-docker-vm (2026-09-27, Prime go-ahead; ha-dev request)