httpYac for Zed

HTTP request support for Zed, backed by httpYac. It keeps the IntelliJ .http request syntax and environment file format while exposing Zed-native runnables and tasks.

Features

• .http and .rest syntax highlighting
• inline runnable actions for individual requests
• JSON, XML, GraphQL, and JavaScript body injection
• request outline entries and starter snippets
• send the request at the cursor, every request in a file, or use httpYac's interactive picker
• pretty-printed JSON response bodies with terminal syntax colors
• HTTP, GraphQL, WebSocket, MQTT, and gRPC support through httpYac
• IntelliJ-compatible http-client.env.json and http-client.private.env.json
• Cmd-click / Go to Definition from {{variables}} to selected environment values
• Cmd-click / Go to Definition from # @env to the environment declaration
• undefined environment and variable diagnostics with creation quick fixes
• automatic fallback to the first declared environment when none is selected
• .env, .env.<environment>, and <environment>.env support from httpYac

Requirements

• Zed
• Node.js 18 or newer, including npx
• Rust installed through rustup with the wasm32-wasip2 target for development-extension builds

The tasks pin httpYac 6.16.7. npx downloads it on first use and reuses the npm cache afterward. A project-local or global setup can override the supplied tasks if preferred.

Install as a development extension

1. Run rustup target add wasm32-wasip2 in a terminal.
2. Open Zed's command palette.
3. Run zed: install dev extension.
4. Select this repository directory.
5. Open an .http or .rest file.

Send requests

Click the runnable action next to an HTTP method, or open the task picker with Cmd+Shift+R / Ctrl+Shift+R and choose an httpYac: task.

# @name get-user
GET https://api.example.com/users/42
Accept: application/json

The response exchange is shown in Zed's terminal panel.

JSON objects and arrays in the exchange are pretty-printed with syntax colors for keys, strings, numbers, booleans, and null values. Set NO_COLOR=1 before starting Zed to disable ANSI colors.

IntelliJ-compatible environments

Use the same public file as IntelliJ:

{
  "development": {
    "baseUrl": "https://dev.example.com",
    "token": "public-placeholder"
  },
  "production": {
    "baseUrl": "https://example.com",
    "token": "public-placeholder"
  }
}

Save it as http-client.env.json. Put secret overrides in http-client.private.env.json using the same structure:

{
  "development": {
    "token": "development-secret"
  },
  "production": {
    "token": "production-secret"
  }
}

Keep http-client.private.env.json out of version control.

The extension searches both files in the same places supported by the IntelliJ environment provider:

1. next to the .http / .rest file
2. each parent directory up to the Zed worktree root
3. the worktree root's env/ directory

The supplied tasks run from the request file's directory. httpYac still walks up to the worktree root for environment discovery, while avoiding an expensive full-worktree glob scan in large projects.

Select an environment per request

Zed does not currently expose a custom editor-toolbar dropdown to extensions. Add a lightweight # @env directive and use the runnable on that directive:

### Get a user
# @env development
# @name get-user
GET {{baseUrl}}/users/42
Authorization: Bearer {{token}}

# @env only selects the top-level environment name; the environment files stay byte-for-byte compatible with IntelliJ. If a request has no directive, the regular runnable selects the first top-level environment in file order. $shared and $default are not treated as environment names.

Place # @env before the first ### separator to select that environment for every request in the file. A directive inside an individual request overrides the file-wide selection.

Hyphenated IntelliJ keys such as {{ai-api-client-basic}} can stay unchanged. Before execution, the runner translates those names in a private temporary request copy so httpYac does not interpret the hyphens as JavaScript subtraction. The original request file and environment files are never modified.

For one environment across a Zed session, export HTTPYAC_ENV_NAME=development before starting Zed and use the httpYac: Send request in development task.

Environment selection follows this order:

1. the request section's # @env directive
2. HTTPYAC_ENV_NAME, when set
3. the first declared environment in the first discovered environment file

TLS certificate verification

TLS certificate verification is enabled by default. To disable it for every request in one file, add # @tlsVerify false before the first request separator:

# @tlsVerify false

### Call a local development server
# @env local
GET {{baseUrl}}/health

Inside a request section, the same directive applies when that request is sent individually. A request directive overrides the file setting; the Send all requests task uses only file- or project-level TLS configuration.

To configure the plugin for the whole project, create .zed/httpyac.json at the worktree root:

{
  "tlsVerify": false
}

The order is request directive, file directive, project plugin configuration, then the secure default. When verification is disabled, the terminal prints a warning and the runner passes --insecure to httpYac. The native httpYac # @noRejectUnauthorized metadata remains compatible, but tlsVerify is clearer for new files.

Keep certificate verification enabled for production requests. To trust an internal certificate without disabling verification, start Zed with NODE_EXTRA_CA_CERTS pointing to the PEM certificate bundle.

Navigate to a variable value

Hold Cmd and click a variable such as {{baseUrl}}, or run Zed's Go to Definition action. Navigation uses the same environment selection as request execution and selects the value itself in http-client.env.json or http-client.private.env.json. A private value wins when it overrides the selected public environment. Variables declared in the request with @name = value navigate within the .http file.

The environment name in # @env development is clickable too. It opens the public environment declaration when available and otherwise opens a private-only declaration. Undefined environment names and variables are reported as errors; use Zed's quick fix on the diagnostic to create the missing entry.

Values assigned with client.global.set are available to later request tasks in the current Zed session, including hyphenated IntelliJ names. They are held in a private temporary state file and removed from active use when Zed starts a new session. client.global.clear and client.global.clearAll update that state.

Verify

npm run check

The check compiles every Tree-sitter query, exercises the Go to Definition language server, verifies first-environment selection, and starts a local HTTP server to verify public/private environment merging.

Troubleshooting syntax highlighting

Development installs compile the pinned Tree-sitter parser into the ignored local grammars/ directory. If that directory is removed, reinstall the development extension to rebuild it, then run zed: reload extensions. Check zed: open log for failed to load language HTTP if highlighting still does not appear.

If a request only shows a loader, rebuild the development extension to pick up the latest tasks. Each request runs from the .http file's directory and stops after 60 seconds. Add # @env environment-name for an explicit environment; otherwise the first declared environment is used.

Scope

The extension uses Zed's language-extension surface: syntax, runnables, snippets, outline entries, Go to Definition, and terminal responses. Zed does not currently let third-party extensions add an IntelliJ-style response pane or environment dropdown, so those interactions are represented by native tasks and # @env runnables.