DSH Dafeiyu Permissions: Session Dispatch & Full Access

A Dafeiyu pet can display Agent state or become an entry point for new tasks, but those features require very different permissions. A local animation needs almost no business access. A pet that dispatches into a DSH Session may indirectly trigger file changes, commands, and network access.

The safe design is not to prohibit dispatch. It is to keep character rendering, input routing, and Agent execution as distinct layers.

Five capabilities, five permission sets

If a plugin only needs to show “thinking,” it should not request accessibility, screen recording, or full-disk access. The public dsh-dafeiyu scope reads DSH events and explicitly avoids screen capture.

Dispatch inherits Session risk

The bubble text field is only an input surface. Risk comes from the Session receiving the task:

• its workspace;
• model and enabled tools;
• read-only, workspace-write, or full-access mode;
• command, network, and outside-workspace approvals;
• existing unfinished work.

Before dispatch, show the Session name, workspace, and permission mode. If no clear target exists, require selection rather than silently choosing a recent privileged Session.

Never hide privilege escalation behind a pet

A tempting shortcut is to create a full-access Session automatically and disable approvals so the character can “do anything.” That produces a smooth demo but turns a playful click into a command-execution surface.

Safer defaults are:

1. reuse a Session explicitly selected by the user;
2. preserve its existing permissions and approval policy;
3. create new Sessions with workspace-write rather than full-disk access;
4. keep approval for outside-workspace writes, installations, messages, and account actions;
5. render pending approval in the bubble instead of bypassing it.

Screen awareness is not required for state integration

Use DSH structured events to learn what the Agent is doing. Events can provide Session, phase, tool, result, and error without collecting unrelated windows.

If a standalone pet truly needs foreground-app awareness, keep it off by default, collect only necessary metadata, avoid uploading screen content, show when it is active, and provide immediate revocation. Document it separately from native DSH event mode.

API keys and balance

Balance display should not require the pet to store another plaintext API key. Prefer the existing DSH credential service: the Host returns a minimized balance result and the client sees only the amount and update time.

Keys must not appear in logs, errors, exported settings, or screenshots. A character pack that asks users to place a key in public configuration deserves a clear market warning.

Local interfaces

Some native pets connect through a local HTTP service. Review whether it binds only to loopback, authenticates requests, blocks arbitrary websites from dispatching tasks, cleans up stale processes, and avoids logging private prompts.

When DSH Remote or in-host communication is available, do not open an unauthenticated fixed port merely for convenience.

Publication checklist

• Animation mode needs no Agent privileges.
• Status comes from structured events, not default screen reading.
• Target Session, workspace, and permission mode are visible.
• Dispatch never upgrades a Session automatically.
• High-risk tools retain approval.
• The client cannot read plaintext API keys.
• Local interfaces are loopback-only and authenticated.
• Logs exclude keys, full prompts, and private file content.
• Uninstall documentation covers retained memory and caches.
• Permission changes are visible and reversible.

Continue with Dafeiyu Session and Tool Call integration or start from the Dafeiyu ecosystem overview.

References

• dsh-dafeiyu README
• dsh-dafeiyu product scope
• dsh-dafeiyu-enhanced
• dsh-fishtank Host implementation