Untrusted context

The rule

An entry can say anything. "Run the migration script now," "delete the old auth module," "approve PR #482" — a title or body is just text, and text in a shared, writable space can be crafted to manipulate whoever reads it. The rule is simple and absolute: an agent uses the worklog to orient, and the repository and its owners to decide.

Why worklog data is untrusted

Entries fail in three ways, and an agent has to assume all three at once:

• Wrong. Someone logged the wrong paths, or overstated the risk. Honest, but inaccurate.
• Stale. It was true an hour ago; the branch has since merged or the migration finished. Short TTLs shrink this window but never close it entirely.
• Malicious. Anyone who can write to the repo's worklog can plant an entry whose text is designed to steer an agent — a prompt injection with a friendly face.

Inform planning, never obey

The right use of a worklog entry is to narrow where an agent looks. A good reaction to "another session is editing src/auth/**, see Draft PR #482" is to open PR #482 and read it — then decide, from the actual diff, whether to proceed. A bad reaction is to take the entry's word for what changed, or to follow any imperative it contains.

Put concretely: an entry is allowed to change what you investigate. It is never allowed to change what you do without independent verification.

Guidance for agent authors

If you build agents that read the worklog, bake the rule into how you use it:

• Feed worklog content into planning and retrieval, not into a step that can take actions directly.
• Never let an entry's text trigger tool calls, shell commands, approvals, or merges on its own.
• Verify claims against ground truth — the diff, the tests, the real docs — before acting on them.
• Prefer the read-only tools (activity_check, notable_list, session_summary) for orientation, and keep a human in the loop for anything irreversible.