Wagglet: handing a Claude Code / Codex task to a teammate without sharing the account

[valentina-mkrtu]

Pre-submission Checklist

• This post follows the MCP community guidelines

What would you like to share?

Up front: I work on this, and it is not an MCP server — it sits next to your agent setup rather than inside it. Flagging that so nobody feels baited; mods, remove if it is out of scope for Show and tell.
The problem it solves is one I suspect is common here. On our team some people have Claude Code / Codex subscriptions and some do not. The path of least resistance is passing a login around, which breaks ToS, destroys per-person context, and leaves no record of who ran what.
Wagglet turns a request into a claimable task with a bounded agent prompt attached. Whoever has a subscription claims it and runs it on their own account. The task ships with a read-only context credential scoped to that one claim, so the agent can pull the full brief without anyone handing over keys.
The part that might interest people building agent workflows is the skill file — https://wagglet.com/skill.md — the agent fetches its own task context over an authenticated endpoint instead of having it pasted in. Same instinct as MCP resources, much smaller scope.
Workflow writeup: https://wagglet.com/blog/wagglet-workflow-request-draft-ticket-delivery

Interested in how others here handle the "which account executes this" problem, because the credential-scoping question feels unsolved in general.

Relevant Links

https://wagglet.com/skill.md
https://wagglet.com/blog/wagglet-workflow-request-draft-ticket-delivery

[Grit-77]

The separation between claiming work and lending somebody an account is useful. The lifecycle case I would want to make explicit is: A claims a task, its claim ends, B claims it, and A later submits a reply with the old context credential. Does the old credential lose read access immediately, and is the late result rejected or retained as an explicitly stale attempt? Those are separate effects worth testing.

I maintain dotline, a small single-owner mailbox with claim/reply handling. It uses a shared bearer and is not a substitute for your per-person or per-claim authorization model. Would a shared claim/reply lifecycle fixture be useful for comparing the boundaries without connecting either system to real accounts?

Disclosure: Codex helped prepare this reply. I am responding to the workflow you described here; I have not run Wagglet or verified its credential lifecycle.