2026 DeepSeek Harness Agent Preset: System or User?

The preset works for one developer but changes unexpectedly for another user.

Put personal experiments at the user level, team delivery and controlled workflows at the system level, and use a system-level read-only baseline with limited user extensions on shared Macs.

SECTION 01Who should read this

You should keep reading if you need a personal Agent Preset without affecting other users, distribute one consistent configuration across a team, or control write access and audit responsibility on a shared or cloud Mac.

You can leave this guide if you only need a temporary local experiment and do not share the machine, preset ID, or execution workflow with anyone else.

The decision is not about which directory is easier to reach. It is about who is allowed to define the source, which copy wins when IDs collide, how the preset is redeployed, and who owns the rollback when an agent behaves differently after a change.

SECTION 02The scope decision

A DeepSeek Harness Agent Preset defines the plugin composition, tools, and system prompts used for a session. The official project describes DeepSeek Harness as a plugin-based agent harness built around Cordis, so a preset can influence more than a visible prompt. It can change the capabilities available to the session and the way those capabilities are composed. (github.com)

That is why system-level and user-level storage should be treated as different trust domains:

• User-level Preset: owned by one account, suitable for experiments, temporary tool combinations, personal defaults, and fast iteration.
• System-level Preset: owned by the machine or platform team, suitable for a reviewed team baseline, controlled workflows, and repeatable provisioning.
• Dual-layer Preset: a system baseline that users can extend without replacing the reviewed foundation.

A user-level file can be perfectly valid and still be unsuitable as a team baseline. Successful loading proves that the harness found and parsed the file. It does not prove that the file came from an approved maintainer, contains reviewed tools, or follows your organization’s rollback process.

This distinction matters because an Agent Preset is not the same thing as a permission preset. It is also not the same as Plan Mode or Skills:

• An Agent Preset composes the agent’s plugins, tools, and system prompt.
• A permission preset governs approval or execution boundaries.
• Plan Mode changes the agent’s planning and execution state.
• Skills provide discoverable task capabilities and should be governed by their own placement rules.

Do not place a security decision inside an Agent Preset merely because the names appear together in the interface. Verify the relevant subsystem separately.

SECTION 03Preset directories and source trust

The official repository currently includes built-in preset definitions and a writable location for custom presets. Its interface also supports duplicating built-in presets and opening the folder where a custom agent.cordis.yml composition is stored. Preset changes do not retroactively alter an already-running session; the preset is fixed when that session starts. (deepwiki.com)

For your deployment record, capture the actual roots exposed by the version you are running rather than copying a path from an older guide. The confirmed configuration model includes multiple preset roots, system and user trust labels, a user-root enable or disable control, and an ordered scan process. The exact built-in directories, UI entry points, and precedence rules must still be checked against the current release before production rollout.

This gives you a practical trust rule:

• Put a preset at the user level when the user is the only person affected and the content is still changing.
• Put a preset at the system level when other users must receive the same behavior and the source must be reviewed.
• Do not treat a user-level preset as trusted just because it was generated by an Agent or loaded successfully.
• Do not put credentials, customer-specific paths, or hidden security assumptions inside a preset intended for broad distribution.

Cordis is relevant here because DeepSeek Harness uses a plugin-oriented composition model. A preset may therefore be a compact control point for several runtime capabilities, not just a display profile. (deepwiki.com)

SECTION 04Directory choice for DeepSeek Harness custom Presets

If you are asking where a DeepSeek Harness custom Preset should go, first classify the ownership rather than starting with a path:

• Personal ownership: use the writable user root.
• Team ownership: use the system root or a managed deployment mechanism that materializes the system root.
• Project-specific behavior: keep the project-specific source separate from the machine baseline unless the official version explicitly supports project-scoped Agent Presets.
• Shared Mac delivery: use a system root that ordinary accounts cannot modify, then permit only documented user-level additions.

Do not guess the path from the preset’s display name. The interface may show a localized or friendly name while the loader uses an internal ID and a filesystem root. The official source includes preset authoring tests and built-in preset definitions, which are more reliable than screenshots or community summaries. (deepwiki.com)

Record these fields for every deployed preset:

• Preset ID.
• Human-readable name.
• Source root.
• Trust classification.
• Harness release or commit used for validation.
• File owner and group.
• File mode and directory mode.
• Deployment timestamp.
• Reviewer or change ticket.
• Previous version retained for rollback.
• Result of the duplicate-ID test.

The exact directory is a versioned implementation detail. The ownership record is the durable operational rule.

SECTION 05Duplicate IDs and scan order

When multiple preset roots exist, the actual loading result depends on scan order and duplicate-ID handling. A preset named code, standard, or any other familiar label is not proof that the copy you edited is the copy being used.

Use a minimum same-name test before you distribute anything:

1. Create two harmless presets with the same ID in two different roots.
2. Give each copy a visibly different, non-sensitive marker, such as a unique description or a harmless system-prompt sentence.
3. Restart the harness or create a new session, because existing sessions keep the preset composition they started with. (deepwiki.com)
4. Select the duplicate ID and record which marker appears in the new session.
5. Remove the test copies and repeat the check after every release upgrade that may change configuration loading.

This test answers which copy wins. It does not answer whether the winning copy should be trusted. Keep those questions separate.

Do not infer precedence from:

• The order of cards in a settings panel.
• The alphabetical order of names.
• The directory modified time.
• A successful launch.
• A preset’s localized display label.
• A previous version’s behavior.

A reliable deployment note should say, in plain language, “root A was scanned before root B, duplicate ID X resolved to root A,” or record the opposite result if that is what the tested version does. If you cannot write that sentence with evidence, you do not yet have a safe distribution rule.

SECTION 06Decision conditions

Use this branch list when selecting the placement:

• If one developer owns the workflow, the preset is experimental, and no other account depends on it, choose user-level.
• If the preset must be identical for a team, choose system-level and deploy it from a reviewed source.
• If users need personal additions but must inherit a controlled baseline, choose system-level read-only plus user-level limited extensions.
• If a preset contains credentials, customer paths, approval assumptions, or mandatory safety behavior, do not place those details in an unrestricted user root. Move the controlled portion to the system layer or a separate secured mechanism.
• If you cannot identify the active duplicate after a same-name test, stop distribution and fall back to one enabled root until the scan behavior is documented.
• If the Mac is shared across unrelated customers or projects and user extensions can cross those boundaries, stop sharing the same preset root and use separate accounts or separate environments.
• If rollback requires an administrator to search unknown directories manually, the system-level delivery is incomplete. Package the source, version, permissions, and restore action together.

This is the core selection rule:

User-level optimizes iteration. System-level optimizes consistency. The dual-layer model is the safer default for shared Macs.

SECTION 07Team delivery and rollback

A system-level Preset has value only when it can be recreated. Manual copying from an engineer’s home directory is not team delivery; it is undocumented state transfer.

For each release, store a deployable source package with:

• A stable preset ID.
• A version identifier.
• A change summary.
• A list of included plugins and tools.
• A compatibility note for the target DeepSeek Harness release.
• A file permission policy.
• A checksum or equivalent integrity record.
• A previous known-good version.
• A validation command or session procedure.
• An owner responsible for rollback.

The official repository is in developer preview and warns that compatibility-breaking changes may occur. That makes release pinning and revalidation especially important for teams that rebuild Macs or scale remote environments. (github.com)

A good rollout is not “copy the new file and restart.” Use this sequence:

1. Validate the preset in an isolated account or test machine.
2. Confirm the expected source root and trust label.
3. Run the same-name test if another root can contain the same ID.
4. Start a fresh session and verify the selected composition.
5. Run one representative task with non-sensitive test data.
6. Deploy the reviewed version with restrictive ownership and write permissions.
7. Retain the previous version until the acceptance test passes on the target Mac.
8. Record the result and the person accountable for reverting it.

The official project also documents a source-based development path using Node.js and pnpm, with current development requirements listed as Node.js 22.19 or newer in the development documentation. Treat those requirements as development-environment facts, not as a reason to copy the entire source tree into a production user directory. (deepwiki.com)

SECTION 08Shared Mac governance

A shared Mac creates three separate risks that are easy to combine accidentally.

First, write access can turn a reviewed baseline into a mutable runtime dependency. One user changes the preset, and the next user receives a different tool composition without realizing it.

Second, account separation may be weaker than project separation. Two accounts can still share machine-level files, caches, environment settings, or administrative ownership. A system-level preset should not be treated as a customer isolation boundary by itself.

Third, rollback responsibility becomes unclear. If a user can modify the active preset but only an administrator can restore it, the organization has created a change path without a matching recovery path.

Choose one of these governance models:

System-level read-only baseline

Use this when all users need the same approved Agent Preset.

• Administrators or the deployment service own the system root.
• Ordinary users have read access but cannot edit the baseline.
• Personal experiments use separate user-level IDs.
• The baseline ID is protected from casual replacement.
• Every update has a previous version and a verification record.

This is the default for a team Mac pool or a remote Mac used by multiple developers.

Limited user extensions

Use this when the baseline is stable but users need personal tools or workflow variations.

• Keep mandatory behavior in the system-level preset.
• Allow user-level presets only under distinct IDs.
• Document whether users may override, extend, or merely select alongside the baseline.
• Prohibit credentials, customer-specific data, and mandatory approval assumptions in personal copies.
• Test collisions between system and user IDs before enabling the model.

This model is useful when developers need rapid iteration without changing the shared foundation.

Fully separated environments

Use this when users work on unrelated customer projects, handle different secrets, or require different trust owners.

• Give each project or customer a separate account or isolated Mac environment.
• Do not rely on different preset names to provide isolation.
• Avoid a common writable root.
• Keep deployment and rollback records per environment.
• Revoke or destroy the environment when the project ends.

If you cannot explain which account can write the root, which account can read it, and who can restore the last known-good version, the machine is not ready for shared Agent Preset use.

SECTION 09Common failure patterns

The first failure pattern is putting everything at the user level because the UI makes authoring convenient. This works for experimentation, but it creates invisible drift when a team assumes everyone is using the same composition.

The second is putting every preset at the system level. That improves consistency but slows legitimate experimentation and encourages developers to bypass the managed root when they cannot iterate quickly.

The third is using the same ID in both roots without testing. This makes a user-level copy look like a harmless customization when it may actually replace or shadow the intended team baseline.

The fourth is confusing an Agent Preset with a permission control. A preset can compose tools, but that does not automatically create a complete security policy. Validate execution permissions through the relevant permission and sandbox controls instead.

The fifth is using Skills as a substitute for preset governance. Skills and Agent Presets have different responsibilities. A team may standardize one while allowing the other to vary, but that decision must be explicit.

SECTION 10A five-step acceptance runbook

Before you approve a DeepSeek Harness Agent Preset for a shared or managed Mac, complete this sequence:

1. Classify the source. Mark it as personal, team-reviewed, vendor-provided, or generated during an experiment.
2. Inspect the roots. Record every enabled system and user root for the tested release.
3. Verify precedence. Use a harmless same-name test and save the observed winner.
4. Check permissions. Confirm who owns the files, who can write them, and whether user accounts can replace the baseline.
5. Prove rollback. Restore the previous version on a fresh session and verify that the expected preset is active.

Do not approve the preset if any step depends on a display name, an undocumented path, or a person’s memory.

SECTION 11Choosing between a local shared Mac and MACNOX

A manually managed shared Mac often fails for the same reasons as a poorly governed preset: writable global files, unclear account boundaries, undocumented changes, and slow recovery after one user modifies the environment. A local setup can still be the right choice when you need physical interfaces, long-term ownership, or full administrative control, but it becomes expensive to operate when each rebuild requires hand-copying configuration and rechecking duplicate IDs.

For temporary team capacity, isolated testing, or a repeatable remote environment, renting a Mac through MACNOX remote Mac access can give you a cleaner boundary: assign the account or machine purpose first, deploy the system-level baseline, and keep user-level experiments separate. If you are preparing a short-lived delivery environment, review the available MACNOX ordering options only after you have defined the preset owner, write permissions, and rollback path.

The right choice is not “system always” or “user always.” Use user-level for personal iteration, system-level for reviewed team delivery, and the two-layer model when a shared Mac must support both consistency and controlled flexibility.