Developer Workstation Standards

Developer workstation standards

Criteria verified as of August 2026. Re-verify on the web before committing to anything (§8).

1. Scope and triggers

The developer's machine is software production infrastructure. It is where the code lives before it exists anywhere else, where the credentials that open production are kept and where third-party code runs with the permissions of a person who has access. It is treated as infrastructure: it is provisioned as code, hardened and can be rebuilt. The three verbs are the thesis, and the third is the one that gets checked.

Operational corollary: "it works on my machine" is not an excuse: it is a provisioning failure, and it has an owner. If the environment that makes the project work is not described in the repository, it does not exist.

Triggers: dotfiles, chezmoi, yadm, GNU stow, bootstrap script, Brewfile, brew bundle, winget import/export, winget configure, flake.nix, home-manager, devenv.nix, .envrc, direnv allow, mise.toml, .mise.toml, .tool-versions, mise, asdf, nvm, pyenv, rbenv, rustup, uv, volta, .devcontainer/devcontainer.json, devcontainer CLI, Codespaces, .editorconfig, .vscode/settings.json, .vscode/extensions.json, .vscode/tasks.json, VS Code / Open VSX extensions, curl | sh, FileVault, BitLocker, LUKS, ed25519-sk, ecdsa-sk, -O resident, -O verify-required, ssh-agent, gpg.format ssh, user.signingkey, credential.helper store, ~/.git-credentials, ~/.netrc, _netrc, shell history, build time, coding agent running locally.

Not applicable: see macos-fleet-standards (critical boundary over the same hardware: the corporate fleet is theirs — automated enrolment and supervision, MDM and declarative management, FileVault key escrow, pre-configured TCC, enforced update policy, software catalogue and CIS/mSCP compliance —; here the workstation of whoever programs, which is provisioned as code, hardened and rebuilt. They are two different problems and the conflict between them is real: a well-made fleet policy breaks development tools if permissions are not pre-configured, and that negotiation is resolved by naming both parties, not by ignoring one), linux-administration-standards and rhel-fedora-standards (the server and the managed fleet are theirs: init, system packages, mass patching, server configuration management; here one person's working machine, which is neither managed the same way nor switched off the same way), linux-hardening-standards (the CIS server baseline and operating system hardening are theirs; here workstation hardening: laptop encryption, screen lock, key custody, third-party code the editor executes), homelab-standards (the personal lab is theirs: tinkering, home services, learning by breaking. Here the tool you get paid with; the boundary is hard and runs in both directions — §7 forbids using the work laptop as a lab server), secrets-management-standards (owner of the choice of secrets manager and secret scanner, of the rotation policy and of the process after a leak. Here only where credentials CANNOT be on this machine and that scanning happens before the commit), identity-access-management-standards (SSO, corporate MFA, account life cycle, privileged access; here its landing on the workstation), git-workflow-standards (commit signing as a repository policy is theirs: requiring it, verifying it, CODEOWNERS, protected branches. Here the custody of the key it is signed with — that it lives in hardware and not in ~/.ssh in the clear), cicd-standards (parity between what runs locally and what runs in CI is defined there; here the obligation that the local machine can reproduce it: same runtime versions, same formatters, same hooks. A lint that passes locally and fails in CI is a failure of this skill), container-runtime-security-standards and podman-systemd-containers-standards (the container runtime and its hardening; here only its use as a development environment), endpoint-security-standards (third-party EDR and the posture of the encryption guard across the fleet — which product, what is required of it and how coverage is measured — are theirs; here the encryption and the keys of this machine as a decision of whoever uses it), ai-agent-workflow-standards (reciprocal, already declared from their side: the working process with coding agents is theirs — what is asked of them, how their output is reviewed, how it fits the flow, indirect instruction injection, accountability for the diff. Here only hardening: which permissions, what filesystem scope and which credentials the agent reaches from this machine, §5.7), claude-code-skills-standards (skill authoring), bash-linux-scripting-standards and powershell-standards (the quality of the bootstrap script — set -euo pipefail, shellcheck, idempotence — is theirs; here what that script has to do), iac-standards (IaC for real infrastructure) and performance-engineering-standards (sister skill of this wave: the performance of the product. Here the performance of the machine, which is team time, not user latency — §6).

2. Default decisions

Verify the latest version and the licence on the web before fixing it (§8).

2.1 Provisioning

mise versus asdf, status verified as of August 2026 — the comparison has changed and the old guides lie:

• asdf was rewritten in Go in 0.16.0 (it used to be Bash). It is a binary, it is much faster than the Bash version, and it removed commands from the Bash era (asdf global, asdf local, asdf shell). Verified version: v0.20.0 (7 Jul 2026). Any internal documentation or script using asdf global/asdf local is broken, and that is the real cost of migrating, not performance.
• The performance argument has deflated: mise's documentation acknowledges that, against asdf in Go, the speed difference is now a minor reason; the remaining reasons are supply chain security, ergonomics and not depending on shims.
• mise is withdrawing asdf plugins for supply chain reasons: its documentation states that asdf plugins are considered legacy and that no new asdf or vfox plugins are accepted in its registry, directing to the aqua (preferred) or github backends. This is a security criterion, not a matter of taste: an asdf plugin is a third party's shell script that runs on every directory change.
• Hard rule: one single version tool per machine. mise and asdf inject hooks into the shell and conflict if both are present.

Choice criterion, short: mise by default for a polyglot team; the native managers if the team is single-language; Nix/devenv only if somebody really maintains it.

2.2 The reproducibility ladder — climb only as far as needed

When a remote or ephemeral environment pays off, and when it does not:

• Yes: when the build needs more machine than fits in a laptop; when the code or the data has to be isolated from the device (contractors, compliance, regulated data); when onboarding new people is frequent and the cost of setting up a machine dominates; when the project needs a topology impossible locally.
• No: when the team works with a bad or intermittent network (bad typing latency destroys more productivity than any CPU compensates for); when the work is interactive with a GUI or local devices; when nobody has calculated the bill.
• Always: the cost is hourly and runs while nobody is looking. Automatic shutdown on inactivity from day one, not as a later improvement. And the remote environment does not exempt you from hardening the laptop: it still holds the credentials that open the remote environment.

2.3 Editor configuration: in the repository, not on the machine

• .editorconfig in the repository, always. It is the only thing every editor understands.
• Formatter and linter configuration goes in the repository (.prettierrc, biome.json, ruff.toml in pyproject.toml, .clang-format, rustfmt.toml, .golangci.yml), with the tool version pinned. The specific tool is chosen by the language skill; the criterion here is where the configuration lives and that the version is pinned.
• A formatter whose version is not pinned produces different diffs per person and turns every PR into noise. It is the most common shared-configuration failure.
• Never depend on each person's editor "format on save" as a guarantee: the guarantee is the pre-commit hook and the CI gate. Editor configuration is convenience; the gate is the contract (cicd-standards).
• .vscode/extensions.json recommends; it does not install silently. It is reviewed as code, with the same suspicion as any dependency (§5.6).

3. Structure: what is versioned

dotfiles/                     # own repository, public or private depending on contents
├── install.sh                # idempotent bootstrap, runnable N times without breaking
├── Brewfile / winget.json    # per-system package manifest
├── shell/                    # shell config WITHOUT secrets
├── git/                      # gitconfig with includeIf per context (personal/work)
├── ssh/config                # config YES; private keys NEVER
└── README.md                 # what it does and what it does NOT do

<project>/
├── .editorconfig
├── mise.toml                 # project runtime versions
├── .envrc                    # NON-secret variables; references to the secrets manager
├── .devcontainer/            # if applicable
├── .vscode/                  # shared settings and tasks, reviewed in PR
└── .pre-commit-config.yaml   # or equivalent: formatting, lint, secret scanning

Hard rules:

• The dotfiles repository contains no secrets. No private keys, no tokens, no real .env files, no histories. References to the secrets manager, yes.
• The bootstrap script is idempotent and non-interactive by default. A bootstrap that only works the first time is useless for the case that matters: rebuilding in a hurry.
• Git configuration separates contexts (includeIf gitdir:): personal and work identity, email and signing key are not mixed. Signing a work commit with the personal identity is a personal data leak, as well as a mess.
• ~/.ssh/config versioned, private keys never. Not encrypted, not "the repo is private".

4. The test that validates all of this: the rebuild

Provisioning that has not been tested does not exist. It is the same criterion as a backup with no tested restore.

• Periodic rebuild exercise: set the machine up from scratch — or a clean VM, or a container — with the bootstrap, and time it. The target is set per team (§8: this skill does not invent a number), but the criterion is binary: at the end, can you clone the main repository, build, pass the tests and deploy? If an undocumented manual step is missing, the failure belongs to the provisioning and is fixed there, not in the wiki.
• Minimum cadence: every time somebody new joins (their onboarding is the test, and their friction is the result), and on any major operating system change.
• Parity with CI, checked: the runtime versions declared by mise.toml / .tool-versions are the same ones the pipeline uses. It is verified automatically, not by habit. A green lint locally and red in CI means parity broke and it is a failure to fix, not a nuisance to tolerate. The pipeline belongs to cicd-standards; the obligation to reproduce it locally belongs here.
• The machine is not a pet. If losing it hurts for any reason beyond rebuild time, there is unversioned state that should be versioned. That state is identified and taken off the machine.

5. Workstation security — the critical section

The workstation is the highest-return target in the supply chain: it has the code before review, the production credentials and the trust of every system it connects to. And the 2025-2026 evidence is that it is attacked there (§5.6).

5.1 Non-negotiable base

• Full-disk encryption enabled and verified: FileVault, BitLocker (with TPM and PIN or boot password), LUKS. Verified, not "enabled during onboarding": its status is checked. An unencrypted laptop is a leak waiting for a taxi.
• Recovery key escrow off the machine itself, in the corporate manager.
• Automatic screen lock with a short timer and lock on closing the lid.
• Phishing-resistant MFA (FIDO2/WebAuthn) on the corporate account, the operating system account and the version control and cloud ones. SMS and TOTP are not equivalent: the criterion and its rollout belong to identity-access-management-standards.
• Automatic system and browser updates, with an agreed maximum window for reboots. Postponing indefinitely is forbidden: it is the cheapest vulnerability to close and the most deferred.
• Everyday account without permanent administrative privileges; ad-hoc elevation.
• Encrypted backup of the irreplaceable (backup-recovery-standards).

5.2 SSH and signing keys: in hardware

• The private key must not be copyable. With a key in a file, a single piece of malware — or an editor extension, §5.6 — exfiltrates it without a trace and without anyone noticing until it is used.
• FIDO2-backed SSH keys, verified status: OpenSSH added support in 8.2 (14 Feb 2020) with the key types ecdsa-sk and ed25519-sk. Verbatim from that release's notes: "This release adds support for FIDO/U2F hardware authenticators to OpenSSH... In OpenSSH FIDO devices are supported by new public key types 'ecdsa-sk' and 'ed25519-sk'" and "FIDO tokens also generally require the user explicitly authorise operations by touching or tapping them." Relevant options and the version they appeared in:
  • -O resident — key resident on the token, recoverable on a new machine: 8.2.
  • -O verify-required — requires a PIN in addition to the touch: 8.4 (authorized_keys accepts verify-required from the same version).
  • no-touch-required — relaxes the touch requirement: 8.2. Used only with a written reason; the touch is precisely the defence against silent use of the key by malware with access to the agent.
  • Verified current version reference: OpenSSH 10.4 / 10.4p1 (6 Jul 2026).
  • ed25519-sk is not supported by every token; ecdsa-sk is the more universal fallback. It is checked before buying the hardware, not after.
• Two tokens, always. A primary one and a backup one registered on the same services, kept somewhere else. A single token is a single point of failure shaped like a keyring, and the day it is lost you cannot get in to fix anything.
• Commit signing with a key in hardware: Git supports SSH signing since 2.34 — verbatim from its release notes: "In addition to GnuPG, ssh public crypto can be used for object and push-cert signing. Note that this feature cannot be used with ssh-keygen from OpenSSH 8.7, whose support for it is broken. Avoid using it unless you update to OpenSSH 8.8." Configuration: gpg.format = ssh + user.signingkey pointing at the token's public key. The policy of requiring signatures belongs to git-workflow-standards; here only that the key is in hardware. Operational detail that makes verification fail on GitHub: the key must be added as a signing key, not (only) as an authentication key — they are two different entries even though it is the same material.
• Keyless alternative for automation: gitsign (Sigstore) signs with an ephemeral OIDC identity and a transparency log. It is not a substitute for the hardware key in daily human work, and GitHub does not display its signatures as "Verified" the way it does SSH or GPG ones: it is a different posture, verifiable with its own tool. Verify status (§8).
• GPG: if used, on a smart card (OpenPGP card / YubiKey), never in a file.
• The agent: ssh-agent with a bounded lifetime and no agent forwarding by default (ForwardAgent). Forwarding the agent to a host is giving that host the use of your keys for as long as the session lasts; if it is unavoidable, ProxyJump instead.

5.3 Credentials: where they CANNOT be

FORBIDDEN, with no exceptions and no "it's temporary":

• ❌ Token in ~/.netrc or _netrc. Plain text, read by a multitude of tools, with no scope and no expiry.
• ❌ git config credential.helper store. Its own documentation says it verbatim: "Using this helper will store your passwords unencrypted on disk, protected only by filesystem permissions." Alternatives the documentation itself points to: cache (memory, ephemeral) or a helper integrated with the operating system's secure store.
• ❌ Secrets in versioned shell configuration files (.zshrc, .bashrc, .profile). It is the classic leak: the dotfiles repository goes public one Tuesday.
• ❌ Secrets in the shell history. An export TOKEN=... or a curl -H "Authorization: ..." stays in ~/.zsh_history forever. Minimum mitigation: leading space with HIST_IGNORE_SPACE/HISTCONTROL=ignorespace, and read the secret from a file or from the manager, never write it on the command line.
• ❌ Secrets in global, permanent environment variables. Every child process sees them: the coding agent, the linter, the editor plugin, a dependency's postinstall script. Scope is bounded per project and per session.
• ❌ A real .env outside the .gitignore, or a .env.example carrying real values.

What you do instead: the secrets manager and the scanner — including their selection — belong to secrets-management-standards. This skill's own criterion is about location and timing: credentials in the system keychain or in the manager; short-lived and with minimum scope (OIDC instead of static tokens whenever it exists); and injected into the process that needs them, when it needs them.

Secret scanning before the commit, not after. A secret that reaches Git history is already compromised: rewriting history does not dislodge it from clones, forks, CI runners or caches. The only correct response to an already-pushed secret is rotating it. That is why the local pre-commit hook is mandatory, and server-side scanning too — the local hook is skipped with --no-verify and it will be skipped. The specific tool is chosen by secrets-management-standards.

5.4 curl | sh: the same risk that is forbidden in CI

The whole argument fits in one sentence: running a remote script without pinning a version or verifying provenance is exactly what cicd-standards forbids in the pipeline — and there are more credentials on the workstation than on the runner. Whoever requires digest pinning and signature verification in CI and then installs their toolchain with curl | sh does not have a supply chain policy: they have one for other people's machines.

The failure modes, concretely:

• The server serves what it wants, to whom it wants. The URL's content is neither pinned nor signed, and it can change between two runs without anyone noticing.
• Pipe detection: the server can detect that it is being piped into sh — through the interpreter's read backpressure — and serve different content from what you would get by downloading it to read it. That is: inspecting the URL in a browser proves nothing.
• Partial execution: a network drop halfway leaves the system in an undefined state, with half the script executed.
• ⚠ A sha256 published on the same origin as the script adds almost nothing: whoever controls the origin controls both. What does add value is a signature (Sigstore/cosign, the vendor's GPG) verified against a key known through another channel.

Criterion, in order of preference:

1. System package manager package (Homebrew, winget, the distribution, Nix). It is the default option and the one that almost always exists.
2. Versioned artifact with a verified signature (or, failing that, with a checksum obtained through a different channel), pinned to a specific version, never to latest/master.
3. Script downloaded to a file, read and pinned by version, then executed. It is not equivalent to point 2, but it is honest.
4. Blind curl | sh: FORBIDDEN (§7).

5.5 Automatic execution of project configuration

Cloning a repository should not execute anything. In practice, it executes quite a lot.

• direnv: .envrc is arbitrary shell code that runs on entering the directory. That it requires direnv allow is the defence, and it works only if the file is read before authorising it. Authorising by reflex is worse than not having direnv, because it also gives a sense of control. It is re-authorised and re-read on every change to the file.
• .vscode/tasks.json and settings.json from someone else's repository: they can point at interpreters, formatters and binaries inside the repository itself, which the editor will execute. Opening an unknown repository in the work editor is a security decision. Workspace trust modes are used; they are not disabled because they are annoying.
• Dependency life cycle scripts (npm's postinstall and equivalents) run on install. Hardening the installer belongs to the language skill (frontend-web-platform-standards, python-standards…); here the rule is that the first install of an unknown repository is not done on the work machine, but in a container or a disposable VM.
• The repository's Git hooks do not run by themselves on clone, but any tool that installs them does activate them. They are reviewed the same way.
• Rule that solves 90% of the cases: untrusted repository → disposable container or Dev Container, never the host. And the container without mounting ~/.ssh, or the keychain, or the agent socket.

5.6 Editor extensions and shell plugins: third-party code with your permissions

An editor extension runs with the user's permissions, with no meaningful isolation, with access to the code, to ~/.ssh, to the environment variables and to the network, and with automatic updates. In attack surface terms it is equivalent to installing a stranger's binary and giving it permission to update itself. There are documented and recent incidents — this is not theory:

• GlassWorm (initially documented by Koi Security in Oct 2025, with later waves): a family of self-propagating malware in editor extensions, present both on Open VSX and on the Visual Studio Marketplace. It uses invisible Unicode characters to hide the malicious code from view in the editor. It steals npm, GitHub, Open VSX and Git credentials to compromise more packages — each victim is a new infection vector —, drains cryptocurrency wallets and turns the machine into proxy infrastructure. Verbatim from the March 2026 coverage: "Socket said it discovered at least 72 additional malicious Open VSX extensions since January 31, 2026, targeting developers", and it abuses extensionPack / extensionDependencies so that an innocent-looking package later pulls in the malicious extension, once trust has been won. The lures imitate linters, formatters and AI coding assistants.
• GitHub, May 2026 — the case that closes the debate: a compromised version of Nx Console (nrwl.angular-console v18.95.0), an extension with more than 2 million installations, was published on the Marketplace using stolen publishing credentials. A single workstation belonging to a GitHub employee, with automatic extension updates enabled, was compromised; from the tokens, secrets and SSH keys collected from that machine, the attacker exfiltrated ~3,800 internal GitHub repositories. GitHub publicly confirmed the access on 19 May 2026. The whole chain — extension → workstation → internal repositories — is exactly the threat model of this section.
• Other cases from the period reported by the specialist press: AI-branded extensions with ~1.5M cumulative installations capturing files and code modifications (Jan 2026), and infostealers published in Microsoft's registry (Dec 2025).

Hard rules, and they are uncomfortable on purpose:

• Inventory of installed extensions, reviewed. What is not used gets uninstalled: every extension is permanent surface.
• They are installed out of a concrete need, not out of discovery. Before installing: who publishes it, how long it has been around, what permissions it asks for, and whether it does something the editor already does.
• Popularity is no guarantee: Nx Console had millions of installations. The download count can be inflated and the legitimate publisher's account can be stolen — which is exactly what happened.
• ⚠ Automatic extension updating is the vector. In GitHub's case, the machine was compromised because the extension updated itself to the malicious version during a window of ~11 minutes. Criterion: on machines with access to production or to private code, disable automatic extension updates and update in batches after a waiting window. It costs convenience; the alternative costs 3,800 repositories.
• The same applies to shell plugins (oh-my-zsh and its ecosystem, plugin managers, themes): they are arbitrary shell that runs on every interactive session, often installed with curl | sh (§5.4) and updated from main. They are pinned by version or they are not installed. A pretty prompt theme does not justify permanent remote execution.
• The same rule for version manager plugins (§2.1): that is why mise has stopped accepting asdf plugins in its registry.
• On suspicion that an extension is compromised, the response is to rotate, not to uninstall: every token, secret and SSH key that was on disk is assumed compromised. The keys that lived in hardware (§5.2) are precisely the ones that do not have to be rotated. That is the whole argument in favour of the token, summarised.

5.7 Coding agents on the workstation

The working process with agents belongs to ai-agent-workflow-standards, which already declares from its side that hardening the machine belongs here. Here only the hardening, and the framing is simple: a coding agent is a local process that runs commands with the user's permissions and with an input partly controlled by third parties — the repository's content, a tool's output, a web page, an API response. The threat model of §5.6 applies to it, not that of a desktop tool.

• Filesystem scope bounded to the project. No access to the full home directory, and explicitly no ~/.ssh, keychain, cloud configuration files (~/.aws, ~/.kube, ~/.config/gcloud) or the dotfiles repository.
• Scoped, short-lived credentials, injected into the agent's process and only into it. Never the long-lived personal credentials or the production ones.
• Human approval for irreversible actions: writing outside the project, git push, publishing packages, any command against real infrastructure, installing dependencies.
• No production credentials on the workstation (§7): this skill's general rule becomes critical when there is an autonomous process running commands.
• Risky work goes in a disposable container, not on the host — same criterion as §5.5 for untrusted repositories.
• The agent's output is reviewed as third-party code, with the same review as any PR (code-review-standards). Here all that matters is that the agent is not an identity with trust of its own.

6. Machine performance: the economic argument

The developer's waiting time is opportunity cost, and it is the argument that wins budgets — but only if it is measured instead of felt.

Method, and it must be done with your own data:

1. Measure, do not estimate: incremental and clean build time, time of the test suite that runs before each commit, environment start-up time, editor indexing time.
2. Multiply by the real daily frequency (how many times a day a build actually happens) and by the number of people.
3. Convert to hours per year and value them with the team's internal cost.
4. Compare with the price of the hardware. If the calculation comes out in favour, it is not a comfort request: it is an investment with a calculated return, and that is how it is presented.

This skill fixes no saving figures or multipliers (§8): they circulate on the web with no verifiable primary source. The numbers come from your own machine and your own team.

Concrete constraints that usually dominate:

• RAM is the hard ceiling. Once the system starts swapping to disk, everything else is irrelevant. An editor with indexing, a browser, containers and a local service compete for the same memory.
• The disk: NVMe SSD with enough free space. An almost-full disk degrades performance and makes builds fail in ways that look like a different problem for hours.
• The CPU matters by cores for compilation and by single-thread performance for everything else; it is not the same purchasing decision.
• ⚠ Development containers outside Linux pay an I/O tax on directories mounted from the host. It is the usual cause of a Dev Container "being slow". It is measured before blaming the tool; sometimes the solution is a native volume instead of a bind mount, and sometimes it is not using a container for that project.
• The corporate antivirus scanning the build directory can double compilation time. It is a real and frequent case. It is measured, and an exclusion is negotiated with security, with a bounded scope and in writing — it is not disabled unilaterally (§7).
• Space hygiene: dependency caches, container images and build artifacts grow without limit. Scheduled cleanup, not when the disk fills up at eleven at night.

7. Long-term sustainability and prohibitions

• Workstation configuration is reviewed as code: the team's dotfiles, in a repository, with review. A change to the shared bootstrap is an infrastructure change.
• Cadence: review the inventory of extensions and plugins every quarter (§5.6); review runtime versions whenever the pipeline changes; rebuild exercise at least with every onboarding (§4).
• A new tool = a decision with a maintenance cost. Every provisioning layer (mise + direnv
  • Nix + Dev Container at once) is one more thing that can break and one more piece of documentation that can go stale. Climb the ladder in §2.2 only with a reason.
• Employee offboarding: written procedure for withdrawing the machine — secure erasure, key revocation (including hardware keys registered with services) and rotation of anything it could have touched. It belongs to identity-access-management-standards; here the device part.

Explicit prohibitions:

• ❌ Installing with curl | sh without pinning a version or verifying provenance (§5.4). FORBIDDEN to do it with administrator privileges (curl ... | sudo sh) under any circumstances.
• ❌ An SSH or GPG private key in a file on a machine with access to production or to private code, when hardware is available (§5.2).
• ❌ A token in ~/.netrc, in credential.helper store, in the versioned .zshrc/.bashrc or in the shell history (§5.3).
• ❌ Production data on the local machine. Not a dump "for debugging", not a customer CSV, not a database replica with real data, not logs with personal data. A laptop does not have the access controls, encryption, logging or retention that datum requires — and losing it is a notifiable incident (privacy-engineering-standards, grc-compliance-standards). If debugging with real data is needed, it is debugged where the data lives, with audited access. Anonymised or synthetic data for everything else.
• ❌ Long-lived production credentials on the workstation. Ad-hoc, short-lived, audited access.
• ❌ The work laptop as a server. Nothing others need should depend on a machine that gets closed, carried in a backpack, updated and loses wifi: not a shared service, not a CI runner, not a tunnel others use, not a cron somebody is waiting on. A laptop has no availability, no redundancy, no maintenance window and no successor. It goes to homelab-standards (if it is personal) or to real infrastructure (if it is work). A service whose owner goes on holiday with it in their backpack is not a service.
• ❌ Disabling disk encryption, the screen lock, the corporate antivirus or automatic updates for convenience or performance. Performance exclusions are negotiated with security, with a bounded scope and in writing (§6).
• ❌ Installing an editor extension without reviewing who publishes it, or keeping automatic extension updates on a machine with access to production or to private code (§5.6).
• ❌ direnv allow without having read the .envrc (§5.5).
• ❌ Opening an unknown repository in the work editor or running its install on the host: disposable container (§5.5).
• ❌ SSH agent forwarding (ForwardAgent) by default (§5.2).
• ❌ Two runtime version managers at once (mise and asdf): their shell hooks conflict (§2.1).
• ❌ A formatter or linter whose version is not pinned in the repository, or that only exists in one person's editor configuration (§2.3).
• ❌ An undocumented manual step in the provisioning. If you have to ask somebody to set the machine up, the provisioning is broken (§4).
• ❌ Giving a coding agent access to the full home directory, to ~/.ssh or to the cloud credentials (§5.7).
• ❌ "It works on my machine" as a conclusion. It is the statement of a provisioning failure, and it has an owner.

8. Mandatory web verification

Before fixing any datum of this document in a real team:

1. Runtime version managers: verified as of August 2026 — mise v2026.8.1 (very high release cadence: any version written here expires within days) and asdf v0.20.0 (7 Jul 2026), already rewritten in Go since 0.16.0, which removed asdf global, asdf local and asdf shell. Confirm the status of the withdrawal of asdf plugins from mise's registry (documented as a supply chain reason) and whether asdf has already implemented plugin version locking, which it did not have.
2. Dev Containers: verified — specification under CC BY 4.0 (Microsoft), reference CLI devcontainers/cli under MIT and with recent activity (Jul 2026). Check the feature parity of the specific implementation you are going to use (VS Code, JetBrains, cloud service): it is uneven between them and that is where the time goes.
3. OpenSSH and FIDO2 keys: verified in the official notes — FIDO/U2F support since 8.2 (14 Feb 2020) with ecdsa-sk and ed25519-sk; -O resident and no-touch-required in 8.2; verify-required (PIN) in 8.4; verified current version 10.4 / 10.4p1 (6 Jul 2026). Check whether the specific token supports ed25519-sk before buying it.
4. Commit signing with SSH: verified in the Git 2.34 notes, including the verbatim warning that it does not work with ssh-keygen from OpenSSH 8.7 and you have to be on 8.8+. Git at 2.55.0 as of August 2026. Confirm in the forge's documentation that the key must be registered as a signing key, not an authentication one, for verification to come out as valid.
5. Passkeys and signing: declared gap. As of August 2026 no standard mechanism for commit signing with discoverable passkeys equivalent to the -sk keys has been found; what is verified is that FIDO2-backed SSH keys are the mature route. gitsign (Sigstore) is a different posture — ephemeral OIDC identity with a transparency log — and its signatures are not shown as "Verified" on GitHub the way SSH/GPG ones are. Verify status and version before adopting it.
6. Extension incidents — reconfirm before citing them: the facts in §5.6 come from the specialist press and security vendor reports (Koi Security, Socket, Aikido) and not from primary sources read in full in this verification, except GitHub's public confirmation of 19 May 2026. Data to reconfirm: the figure of ≥72 malicious Open VSX extensions since 31 Jan 2026 (Socket, verbatim in the coverage), the ~3,800 internal GitHub repositories, the version nrwl.angular-console 18.95.0 and the exposure window of ~11 minutes.

…(truncated)