Environment
What happened
After the #87089 fix, remote iMessage photo attachment staging appears to succeed, but the final Codex/tool-facing attachment metadata can still expose the raw macOS Messages attachment path instead of the staged local cache path.
In a live iMessage direct conversation, a user sent a photo attachment. The delivery metadata exposed the attachment path as:
/Users/kaien/Library/Messages/Attachments/.../IMG_0423.jpeg
Trying to inspect that tool-facing path from the Linux agent runtime failed:
unable to locate image at `/Users/kaien/Library/Messages/Attachments/.../IMG_0423.jpeg`: No such file or directory
However, the same attachment had actually been SCP-staged successfully into OpenClaw's local remote cache:
/home/openclaw/.openclaw/media/remote-cache/<session-slug>/IMG_0423.jpeg
Passing that staged local cache path to the image inspection tool worked.
Expected behavior
After remote iMessage media is staged, the final agent/Codex-visible attachment metadata should expose the staged local path, for example:
/home/openclaw/.openclaw/media/remote-cache/<session-slug>/IMG_0423.jpeg
The raw macOS Messages path can remain available as original/debug metadata if needed, but should not be the primary tool-facing media path in a Linux agent runtime.
Actual behavior
- Remote staging succeeded.
- The staged file existed locally.
- The final tool-facing attachment path still pointed at the raw remote Mac path.
- The agent had to manually search the remote cache by basename to inspect the image.
Why this seems related to #87089 but not fully covered by it
#87089 fixed the ordering bug where media understanding could see the raw Mac path before SCP staging. This follow-up appears to be a later metadata propagation issue: staging happens, but the rewritten staged path is not what the final Codex/tool-facing attachment metadata exposes.
Suggested fix
- Ensure the staged local cache path produced by
stageSandboxMedia() is propagated to final agent/Codex-visible attachment metadata.
- Keep the raw remote macOS path only as original/debug metadata.
- Add a regression test that verifies remote iMessage attachments are not exposed to the final agent turn as
/Users/.../Library/Messages/Attachments/... after staging.
Environment
2e08f0fWhat happened
After the #87089 fix, remote iMessage photo attachment staging appears to succeed, but the final Codex/tool-facing attachment metadata can still expose the raw macOS Messages attachment path instead of the staged local cache path.
In a live iMessage direct conversation, a user sent a photo attachment. The delivery metadata exposed the attachment path as:
Trying to inspect that tool-facing path from the Linux agent runtime failed:
However, the same attachment had actually been SCP-staged successfully into OpenClaw's local remote cache:
Passing that staged local cache path to the image inspection tool worked.
Expected behavior
After remote iMessage media is staged, the final agent/Codex-visible attachment metadata should expose the staged local path, for example:
The raw macOS Messages path can remain available as original/debug metadata if needed, but should not be the primary tool-facing media path in a Linux agent runtime.
Actual behavior
Why this seems related to #87089 but not fully covered by it
#87089 fixed the ordering bug where media understanding could see the raw Mac path before SCP staging. This follow-up appears to be a later metadata propagation issue: staging happens, but the rewritten staged path is not what the final Codex/tool-facing attachment metadata exposes.
Suggested fix
stageSandboxMedia()is propagated to final agent/Codex-visible attachment metadata./Users/.../Library/Messages/Attachments/...after staging.