bug(supervisor): plaintext HTTP request is reported to middleware with target.scheme = "https" #4253

User Story

I personally use OpenShell locally on Apple Silicon to test supervisor middleware behavior for external request authorization and operation binding.

My use case depends on the middleware receiving an accurate representation of the application request being evaluated. While using OpenShell v0.1.2 with an HTTP_REQUEST / PRE_CREDENTIALS supervisor middleware, I sent a plaintext HTTP request from an OpenShell sandbox through the inspected REST path.

The authenticated middleware request reported:

target.scheme = "https"

even though the request was plaintext HTTP.

I need HttpRequestTarget.scheme to accurately describe the request scheme so that authorization decisions can be bound to the operation actually being evaluated.

Problem Statement

A plaintext HTTP request can be presented to supervisor middleware with:

target.scheme = "https"

The protobuf contract describes this field as the request scheme, with examples including "http", "https", "ws", and "wss".

In the observed plaintext HTTP path, the middleware representation therefore does not match the request transport being evaluated.

I reproduced this on OpenShell v0.1.2. Inspection of current main shows the corresponding middleware path still supplying "https" for this representation.

Impact / Why This Matters

This prevents middleware consumers from safely using HttpRequestTarget.scheme as part of an authorization or operation-binding decision for plaintext HTTP requests.

In my case, the middleware decision is intended to bind to the application operation being authorized. If a plaintext HTTP request is represented as HTTPS, the middleware consumer must currently choose between:

• ignoring the scheme field, weakening the operation identity being authorized;
• rewriting the field locally based on assumptions outside the documented OpenShell contract; or
• rejecting the request and stopping the workflow.

I chose the third option rather than silently reinterpret the field.

The practical consequence is that my HTTP operation-binding test cannot proceed using the documented scheme field until its semantics are clarified or the representation is corrected.

Acceptance Criteria

• A plaintext HTTP request evaluated by HTTP_REQUEST / PRE_CREDENTIALS is presented to middleware with target.scheme = "http".

• An HTTPS request on the corresponding inspected path is presented with target.scheme = "https".

• The value reflects the documented request-scheme semantics rather than an unconditional constant.

• Existing WebSocket scheme distinctions (ws / wss) continue to remain accurate.

• The behavior is covered by a regression test for both plaintext HTTP and HTTPS middleware evaluation.

Reproduction Steps

1. Run OpenShell v0.1.2 with the VM driver and a sandbox.

2. Register an HTTP_REQUEST / PRE_CREDENTIALS supervisor middleware that records the received HttpRequestEvaluation input.

3. Configure policy so that a plaintext HTTP destination is inspected through the REST/L7 middleware path.

4. From the sandbox, send a plaintext HTTP request to that destination.

5. Inspect the authenticated middleware request.

6. Observe that target.scheme is "https" even though the request is plaintext HTTP.

In my test, the middleware rejected the request because the declared operation contract only accepted HTTP when the representation reported scheme = "http".

Suggested UX (if applicable)

No response

Environment

OpenShell: v0.1.2

Host:

• macOS 26.6.2
• Apple M5
• ARM64
• 16 GiB memory

OpenShell deployment:

• Packaged ARM64 macOS release
• VM compute driver
• Linux 6.12.76 ARM64 microVM guest
• Local gateway at https://localhost:17670
• Supervisor middleware registered for HTTP_REQUEST / PRE_CREDENTIALS
• Middleware configured as the sole/final stage for the test path

The plaintext request originated inside the OpenShell sandbox and was evaluated through the inspected REST/L7 path.

Logs