diff --git a/packages/krpc-client/src/schema.ts b/packages/krpc-client/src/schema.ts
index 5aa6b23..9f8773d 100644
--- a/packages/krpc-client/src/schema.ts
+++ b/packages/krpc-client/src/schema.ts
@@ -36,8 +36,16 @@ const schemaJson = {
               },
             },
             ConnectionResponse: {
+              // NOTE: status is wire-varint-enum-OK=0, but we model it
+              // as a plain uint32 to avoid protobufjs nested-enum
+              // resolution bugs that throw "Cannot read properties of
+              // null (reading 'code')" when the field is omitted from
+              // the wire (which the kRPC server does for the happy
+              // path). Our code already does `resp.status !== 0` /
+              // `!== 'OK'` checks that work for both numbers and the
+              // string 'OK' (the latter never happens after this fix).
               fields: {
-                status: { type: 'ConnectionResponse.Status', id: 1 },
+                status: { type: 'uint32', id: 1 },
                 message: { type: 'string', id: 2 },
                 clientIdentifier: { type: 'bytes', id: 3 },
               },
@@ -80,6 +88,14 @@ const schemaJson = {
             },
             ProcedureResult: {
               fields: {
+                // Same nested-enum-as-field-type issue as
+                // ConnectionResponse.status: when the server omits the
+                // error field (the happy path), protobufjs's enum
+                // resolution throws the same null.code TypeError. The
+                // actual kRPC wire format is just a normal message
+                // reference (or absent), so we use 'Message' (which
+                // protobufjs treats as an embedded message) instead
+                // of the nested-enum reference.
                 error: { type: 'Error', id: 1 },
                 value: { type: 'bytes', id: 2 },
               },